OpenEuphoria

Re: Structures; etc.

• Posted by David Cuny <dcuny at LANSET.COM> Jan 30, 2000
• 508 views

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