OpenEuphoria

Re: Classes: A small proposal

• Posted by Falkon <Falkn13 at IBM.NET> Jun 02, 1998
• 881 views

From:    David Cuny
>You could declare attributes with:
>   point attribute x, y
>which would be internally:
>   global constant point:x = 1, point:y = 2
[...]
>   point function func( integer x )

   Two things I notice about this:
   First, IMHO, constants used by a class should be local to that class, not
using up global namespace.  Otherwise it would negate the modularity of OOP,
being able to plug classes together easily, without extensive modification,
to make a program.
   Secondly, I find the declaration syntax somewhat confusing.  Mixing up
what your declaring with what you're declaring it to be.  My vision of it
goes kind of like this:

-----class declaration-------

class car
   parents = vehicle        --if multiple, then list in order of inheritance
   attributes =
     coordinate position    --assuming coordinate is a declared data type
     integer wheels
     boolean running        --assuming boolean is a declared data type
   methods =
     PROC startup( car )
         ID = routine_ID( "carstart" )
     FUNC driveto( car, coordinate )
         returns boolean
         ID = routine_ID( "cardriveto" )
end class

---------and for object declaration-----

object Mustang
   class = car
   name = "Ford Mustang"      --inherited attribute
   position = { 100, 45 }
   running = NO
end object

-----and for method declaration and attribute setting,----
-----normal EU but with dot notation allowed           ----

procedure carstart( car CarToStart )
   CarToStart.running = YES
end procedure

function cardriveto( car CarToDrive, coordinate Destination )
   if CarToDrive.running then
      CarToDrive.location = Destination
      return( TRUE )
   else
      return( FALSE )
   end if
end function

---------------------------
    My idea would require a separate include file for each class though.
(containing the class structure, descriptors, and methods) so it would need
a project/class/include manager, and a preprocessor, and some other stuff
too...  But it would allow for multiple inheritance, message-passing, and
dynamic overriding of methods.  Plus you could programmatically examine a
class to see what datatype a method's arguments and return value are, and so
on.
    IMHO it looks more natural and more like standard Euphoria, but that's
just my opinion.  And it shouldn't be too difficult to convert existing
libraries to classes...

    To override a method, all you'd have to do is change the value of the
method descriptor's ID variable.  I've wondered whether to disable that.  It
seems most people are opposed to this sort of 'dynamicness', and it could
end up confusing and messy.  But it is possible, and could be powerful.  Now
I see that apparently most people don't like multiple inheritance either,
(though it seems practically necessary from what I understand of OOP).  What
are the arguments against it?  Seems as though it would make combining
classes much easier and prevent a lot of unnecessary code duplication.

     Anyhow, I put everything else aside to play with this.  I'm in the
middle-design stages with ideas scattered through my notebook, half a dozen
text files, a few diagrams, and about a third of one file of the core
routines done.  I think the core routines will be about 5 files containing
message-handling; class, object, property, and method declaration and
manipulation; and program structure code.
     How to enable constraints and multiplicity on the allowed values of a
property is what's bugging me the most...  That and timing.  I can easily
schedule a message to be sent after say...5 iterations through the main
loop, but I can't see any easy way to schedule one to be sent in say, 15
seconds.  Not knowing how long it will take to go through the loop.

     I'll try to put it all together into something less jumbled so the rest
of you can look at it, and maybe make sense of it.  And compare it to the
others.  I have no experience at OO programming, so I could use any
'real-world' thoughts that don't come from a theory book.

From:    Ralf Nieuwenhuijsen
>The reason I wrote this is because I couldn't strap neither your or Irv's
>code.
>Not to have another flavor (althrough like everybody, I'm convienced my
>approuch is the best, I guess its just a personal taste.)

     Diversity is good.  :)  The reason I started on this is that I have had
trouble understanding and figuring out what would need to be modified in the
'custom' systems to make them generic, all-purpose OOP systems.  That and
the quest for clear namespace and easier attribute manipulation.  I'm not
convinced that my approach is the best, in fact it's seeming as though any
of the others would be less complex.  But my idea seems powerful.  Of course
it  hasn't been implemented yet tho.