[Grace-core] super in Grace

[James Noble]

> Hmm ... if the identity of the superclass in Newspeak is dynamic, then must not the identity of the method that super executes be dynamic too?  

yep. basically each class declaration can be interpreted as a mixin...  (or a trait ?:-)

> Not that this affects Grace, since I don't think that we are planning on dynamic superclasses.

Java is heading in this direction with the new "defender methods" on interfaces.

I guess one nice thing about Grace's model is that we can leave the details of inheritance or traits or whatever- much later...

> The overridden getter and setter methods could still be accessed using the super mechanism.   

sure - but once you've overridden a field with *another* field, or a method with a field -
the actual "field" itself will never do a super send - anything overridden by a field is 
only accessible by these "sideways" super calls.

> In fact, this is one reason to allow super-sends of messages with a different name — to more easily allow a method to use an overridden field accessor.

right, without renaming / refactoring..

>>> What about
>>> 
>>> 	self.1.myMessage
>>> 	self.2.myMessage
> 

> How would I know what?   Maybe I didn't explain my proposal very well.  The numbers are just ordinal numbers that refer to the last, last-1 th, last-2 th occurrence of the method for myMessage in the (statically determined) method list.  This needs a diagram!

no, I figured that much out.  I guess there's a question of the linkage model here
(in Java, you can add in itermediate classes up your superclass chain because the 
runtime class universe may not be the same as the compile-time class universe).

I'm afraid I'd prefer C++ - explicitly naming the class where the method is defined - 
to an option with numbers.   But I'd like to see the data - that was where this came in - 
is it worth supporting "sideways" calls or different arguments?

in a closed world, people can always refactor.

James