[Grace-core] super in Grace

James Noble kjx at ecs.vuw.ac.nz
Wed Feb 2 16:48:39 PST 2011


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

Good!

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

yep - I know Antero and like that work.
Here's a more recent paper of his on the same idea: http://lively.cs.tut.fi/publications/TR6-JavaScriptConcatenation-Taivalsaari.pdf

> 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!

yep! just right!

>  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.

indeed - and another thing I like about this - especially important  
for an educational language -
is that it is possible to *show* the result of inheritance, simply by  
displaying the flattened object -
and that flattened object should be a legal object constructor literal  
in the language :-)
(yes it will be odd in that one constructor could have the same field  
in it more than once,
but all execpt the first should be marked @override or something).

> 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

I think so too - probably worth disallowing. I'm reminded of a  
principle I think that comes from Ewan:
coventions / style rules are bad: better to "design away" the error.

> 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.

right - which turns out to be really useful, a "delegated perform" in  
Self, but we don't want that here. not just yet!

> 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.

well there are the two options - one with arity and one with no  
arguments that just calls with the same arguments.
If that was all we really needed (it shouldn't be too hard to ask a  
Smalltalk image about this)
then we could just have a no-args syntax that did it.
Open option for that would just be "super", or "callNextMethod" but  
without arguments...

Hmm, evidence based language design...

James


More information about the Grace-core mailing list