[Grace-core] super in Grace

[James Noble]

Hi Ewan & all

(currently in email so Ewan can read it - will move to grace wiki at  
some point)

so one thing I've been thinking of re Grace is the design
of the inheritance mechanism - specifically the "super"
mechanism (or something like it).    C++ for example lets
methods explicitly call methods in named superclasses -
I'm ignoring that option for now!

Note that - with refactoring of the class hierarchy -
all uses of super or call-next-method/proceed
can be turned into "normal" self sends (at the cost of
adding in extra wrapper methods perhaps).
But to teach inheritance we need some "super"
like mechanism, I think.


Java pretty much follows Smalltalk's design for super:
you can send any message to "super" and it is resolved beginning
at the superclass:

method foo(int i) {
   super.foo(i * 2)
   super.bar()
}

There is another simpler mechanism used by CLOS, R (apparently)
and Aspect/J - call-next-method, aka proceed().
here, rather than naming the method, you simply write
"call-next-method" and the "next" method found by lookup
is called.  This is the same as super *provided* the message
being resent is the same ("foo" in the example above).
"call-next-method" does *not* let methods start the lookup
for *other* methods in superclasses (like super.bar() above)

CLOS has two forms of call-next-method - one (that like super)
lets programmers change the arguments sent to the method,
the other that simply resends with the *same* arguments
(permitting only super.foo(i))

So we have the following design space for "super"

* full generality of Smalltalk/Java super sends?
     - change method name & arguments
  * full call-next-method
     - changes arguments but NOT method name
  * restricted call-next-method
      - calls next method with same arguments


One way to choose - and particularly why I've cc:ed Ewan - is
to analyse existing code, Java, or Smalltalk, or I guess C# (or  
self! :-)
We could look at how super is used: what proportion uses
each of the options above.  Then we can chose a mechanism
that will cover all the most likely cases, and let people
refactor for less common cases.

cheers

James, flushing email queue