[Grace-core] super in Grace

[Kim Bruce]

I'm finally catching up with this conversation on "super".

My main concern is that the meaning of "super" in all languages that I know of is static.  That is, if I write
class C ... extends B {
   method m(...) {
         super.m(...)
         ...
   }
...
}

and then

class D ... {
   ....   // no overriding of m
}

Then when the inherited m is executed, super.m still results in executing the version of m from B.  This is a GOOD thing if you start looking at examples of where you might want to do this (horrible tangles would result if it was reinterpreted when inherited).

So, while I agree that it is confusing to have it look like a message send, we must end up with an implementation and surface syntax that make sure that it stays static like current languages.

Kim

P.S.  A few more details on the syntax, type-checking, and semantics of super are available in chapter 14.1 of my FOOL book -- I'm sure you all have it sitting open on your desk!

P.P.S.  Go Packers!! (The superbowl starts in 30 minutes for those of you out of the states.)


On Feb 3, 2011, at 2:04 AM, James Noble wrote:

>> By gads, Batman!
> 
> sometimes I amaze even myself (as Han Solo would say)
> I do like the idea of basing inheritance on a very simple "record algebra".
> 
>> I han't thought about allowing an object constructor with multiple occurrences of the same method as legal /syntax/.  But: why not?
> 
> it would be a bit confusing, but not too bad, I think.
> 
>> What about multiple occurrences of the same field?  Not a problem, because all fields have unique names, so it can't happen.
> 
> a field is just a getter and a setter method, so it can happen - but one of the fields would be redundant.
> 
>> If we allow that syntax, then there should be some way of getting to the overridden method (i.e., the method in the (n-1)th  method declaration)  What about
>> 
>> 	self.1.myMessage
>> 	self.2.myMessage
>> 
>> to send to the (n-1)st and (n-2)nd method.  Ordinary message send is self.0.message.  And no, you can't omit the self in these special forms.
> 
> but how would you know?
> 
> This is why I prefer something along the lines of "call-next-method" or - "run-next-body" or something -
> without being able to change the name - because it's clear what it does even in this kind of arrangement.
> We don't have to keep track of which proto-object various fields or methods originally came from.
> 
>> I'm actually very tempted by this!  It will make delegation first-class, something that I have long wanted.  If we don't' have assignable parent slots (and I don't think that we should), an object s can still explicitly delegate a message to an object other by writing
> 
>> 	other.0.someMessage
>> 
>> Here the .0 says: the final method for someMessage in the object other, but self remains the receiver.
>> 
>> Well, maybe it's not quite first class.   Messages sent to self from other would go to s, but if s had no method, they would not be delegated to other; they would just fail.
> 
> I'm mostly happy with first-class, or almost-first class delegation.
> Self does it with "perform: m delegatingTo: x" which is really all you need.
> If we can convince people, I'd prefer concatenation, perhaps with
> delegation as an extra.
> 
>> Let me see if I can do that.
> 
> OK sure..
> 
> James
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core