OpenEuphoria

Re: Object Oriented Euphoria

• Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Dec 13, 2004
• 505 views

Pete Lomax wrote:
> 
> On Mon, 13 Dec 2004 05:06:36 -0800, Matt Lewis
> <guest at RapidEuphoria.com> wrote:
> 
> >But here would be my question:  What about the subclasses of a and b?
> >Should I look through all of b's subclasses before I check a?
>
> Wasn't that one of the problems with multiple inheritance? If both a
> and b have method1 and method2 wasn't there some reason you couldn't
> use a's method1 and b's method2? (Don't ask me what language I heard
> this about, I have no idea.)
> 
> Anyway it would make more sense to me to be explicit about these
> things, if there is any ambiguity that is. I suppose it is OK to allow
> the compiler to "guess" which method you mean, but allow an optional
> "namespace" qualifier. Rats nests of inherited methods are worse than
> spaghetti gotos, imo, though source-level trace is an obvious aide.

The way I have it set up, you can *always* be specific, if you like,
by specifying the name of the euclass before the dot, then the method 
name, and then the 'euobject' as the first parameter.  There's nothing
inherently special about the datatype of an euobject.  As long as it 
passes normal typechecking, it should be fine (that's the spec, anyway :).


The multiple inheritance would be there to offer a 'default' way of 
doing this.

Mike Nelson wrote:
>
> The complexity is not just in the subclasses, but in the superclasses that a
> and b may have in common. For example,  a and b are both subclasses of c and
> c defines a method x. Both a and b override x to add their own functionality
> and then call c's x method to perform its task. If we have euclass  platypus
> ... as above and have

Yes, the approach I was thinking of taking was to basically ignore the 
fact that there may be some duplicate subclasses.  Then traverse the
tree of subclasses based on a simple hierarchy rule (first or last) 
declared subclass is searched first, and all of its subclasses, using 
the same precedence rule.  I don't care *too* much about the wasted 
effort spent looking at duplicates (assuming I haven't found anything),
since it's all done during compile time, and you can always remove that
by binding/shrouding/preprocessing.

> where platypus overrides x and calls both superclass methods. This will
> result in c's x method being called twice for the same transaction which is
> usually redundant and often an error--though in some cases it is the correct
> behaviour.

There's no automatic calling subclass methods.  Only one routine will be
called (the first one found).  If you want them to call subclass methods,
it will have to be explicitly done within the method.  I wouldn't want 
to have to deal with that as a coder, let alone as a language designer--
it's always sort of bugged me that constructors work like this (in C++
at least), although I suppose I can see the usefulness there.

Matt Lewis