[Grace-core] super in Grace

[Andrew P. Black]

I've been thinking about inheritance too.  Specifically, how it would work with our nested object constructors instead of classes plan.

I found an old paper: Delegation versus concatenation, or cloning is inheritance too, by Antero Taivalsaari (it's in the svn repository).

I really like the simplicity of his proposal for explaining inheritance: just copy the inherited /object/, and concatenate it with the extensions declared here.  What's nice is that this automatically gives us identical methods (which an implementation could share rather than copy, of course), and separate instance variables, i.e., it's just like class inheritance, but does not require classes!  Cloning and concatenation may result in the new object having more than one method with the same name — the copied one and the newly-delcared one.  Super is the way of getting to the copied one.  

I like the full generality of the Smalltalk super-send.  It is generally considered bad style to super-send any message but the current one, but there are one or two places where it gets you out of a hole.  It would be OK to disallow this.

One thing that I don't like is that super.message makes super look like a receiver.  Really what it means is self<supersend>message.  But allowing that would be bad, because then one could write someoneElse<supersend>message.

It would be nice to come up with another syntax that represents the truth more clearly.  Call-next-method doesn't work because it has a different arity every time we call it. 

	Andrew

On 2 Feb 2011, at 01:58, James Noble wrote:

> 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
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core