OpenEuphoria

Re: Classes: A small proposal

• Posted by Falkon <Falkn13 at IBM.NET> Jun 05, 1998
• 569 views

From:    Ralf Nieuwenhuijsen

>People tend to require speed. Esspecially for those large programms all
this
>OOP crap we've been producing 

    Eh, I've wondered about that.  Seems like all the handle lookups and
multiply subscripted sequences might slow things down considerably.  But I
suppose that's the price you have to pay to use OOP, to some degree.

re: multiple inheritance
>    You could inherit it. Or you could have an instance of it, as an
>attribute in your class. Much cleaner.

    Ahh, that makes sense!  Sounds clear.  I hadn't thought of that.  It
would mean nesting deeper and double/triple more subscripting to access a
value I suppose, but it might turn out cleaner in the long run.

re: attribute value constraints
>    I've used a type-check header. For every attribute is also a routine iD
>available to check its value.

     I'm looking at your code and liking that.  I'd hoped to do it 'more
simply', using a semistandard notation for common things like multiplicity
restrictions, but the simpler I try to make it the more complex it gets.  :(

>But the example code above introduces many new keywords and
>new grammer-rules.

    Well, in the case of the declarations, the grammar is pretty much the
same as any Euphoria declaration, except that I left out the brackets and
snipped the redundant parts of the subscripting because it follows a set,
known pattern for every class and object.
The actual underlying data for that example class would look something like
this, but not exactly:

  {"car",
   {"vehicle"},
   {{"position", COORDINATE },
    {"wheels", INTEGER },
    {"running", BOOLEAN}},
   {{"startup", {"car"}, NONE, routine_ID("carstart")},
    {"driveto", {"car", COORDINATE }, BOOLEAN, routine_ID("cardriveto")}},
   {}
  }

  Because in my version, all classes have the same structure of 5 parts;
    { name,  --string
      {parents},  --sequence of strings (1 string if no multiple
inheritance),
      {property descriptors},
      {method descriptors},
      {currently existing instance handles}
    }
  Objects are simply a sequence of 3 parts;
    { name,     --string
      class,    --classhandle (or string name?)
      {values}  --sequence of one value for each property, of the correct
    }              --  datatype and fitting restrictions

  This is different from yours and others, I believe, in that I treat
objects separately from classes.  Because all objects of the same class must
have the same methods and property constraints, there's no need to duplicate
them.

  The only new keywords were class and object.  Object wasn't new, but had a
different meaning.  Perhaps that wasn't clear.  The rest of the 'new' words
were just a way of using preprocessing to eliminate the ugliness and
confusion of defining hundreds of (possibly conflicting) constants for all
your datatypes, classes, and subscripting.  Or declaring everything via
routines.

     That's another thing that bugs me with most of the current models, is
that you must declare complex structures like classes by using lots of
routine calls.  I'd prefer a cleaner declarative syntax.

Of course, to echo a phrase, that's just syntactic sugar.


>Captials, words as "proc", why not use the same word "procedure" as
Euphoria >does?

   Ah, you got me there.  PROC and FUNC were constants, a throwback to when
I started this, before I was thinking in terms of preprocessing.  So PROC
and FUNC can be changed or done away with.  I could just say that any method
which has a return value of NONE is a procedure, any that has a return value
is a function.

>We could even have a true, pure oop system using messages, keeping all
>attributes and class names in sequenses. But even my PII gets a bit scared
>of that.
>    Timing ? You want to go event based ? Please not. I've already been in
>the VB hell.

     Well I don't know about the true or pureness of it, but that is pretty
much my basis.  Reusable classes of data objects with declared instances
communicating through messages and all that stuff.  Speed and RAM usage do
become problems though.  If I did away with the message-handling and
statechecks, classes and objects could still be used for data storage in
functional programs, but that seems to somewhat sidestep the point.

     What I'm going to do is look through Irv's and David's and your code
some more, compare it to my notes, and see if I might do better to just
write a preprocessor based on that existing code.  And then add
message-handling and statecheck code as an optional part of the system for
those programs/people for which it would be appropriate.

Falkon