OpenEuphoria

Re: Structures; etc.

• Posted by The Johnson Family <thedjs at INAME.COM> Jan 31, 2000
• 501 views

Yaaay!
Wonderful! Wouldnt this be great to have? David has even illustrated a way
that a class file would not really be any different from a current include
file - we could probably reuse much of the existing include files, even if
we have full OOP! Just one suggestion - add a single compiler directive that
can be placed in include files to make the class a "static" one - a static
class would not have to be instantiated- it could be used as if it was an
instance- eg, a non-static class would be treated like this:

Graphics Gr1, Gr2
Gr1.HRes = 200
Gr2.Hres = 768

Where a static class would be treated like this:

Graphics.HRes = 1024
Graphics.VRes = 768


Nick
----- Original Message -----
From: David Cuny <dcuny at LANSET.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, January 31, 2000 7:03 AM
Subject: Re: Structures; etc.


> Michael Nelson wrote:
>
> > There seems to be a recurring demand for structures
> > --in Euphoria terms, fixed-length sequences with type
> > specified for each element and named access to the
> > elements, preferably with dot notation.
>
> If Euphoria had classes, you wouldn't need structures. The data would be
> encapsulated into the classes, not in sequences. So you'd avoid having to
> add all that overhead to sequences.
>
> > I'm not sure I see the point in doing this if we are going to stop
there.
> > No doubt implementing structures in the Eu interpreter would require
> > extensive reprogramming.  If Rob were to invest that much time and
effort
> > into redesigning the language, why only go half way to object
orientation?
> > Add access control, methods, and some form of inheritance and you have a
> > true OOP language:  E++.  Is this the direction we want Euphoria to go?
>
> I vote Yes. Implementing namespace *is* OOP. For example:
>
>    class = include file
>    objects = scoped variables
>    methods = scoped routines
>    inheritance = scoped include files
>
> -- BEGIN EXAMPLE --
>
>    -- point.e
>    integer x, y
>
>    procedure init( initX, initY )
>       x = 0
>       y = 0
>    end procedure
>
>    procedure plus( integer dx, dy )
>       x += dx
>       y += dy
>    end procedure
>
> -- END EXAMPLE --
>
> The above example, declares a Point class. Currently, we only get a single
> instance of the class. Namespaces clarifies that we really *are* dealing
> with a class:
>
>    point.init( 10, 20 )
>    point.add( 3, 4 )
>    ? { point.x, point.y }
>
> The only thing that we won't have is the ability to create more than one
> instance. If you add that, you've got a complete OOP system:
>
>    module point declares class point
>    point point1, point2
>
>    point1.init( 10, 20 )
>    point2.init( -30, 10 )
>
> Note that:
>
>    - types don't have to be added to sequences
>    - old code doesn't break
>    - people don't *have* to use OOP
>
> -- David Cuny
>
>