[Grace-core] Inheritance and object initialisation

[James Noble]

> I don't see any reason to be depressed.

Ah, a voice of reason!

>  I'm surprised that you are surprised that Grace is different from Java..  But all that I have seen so far is that the idioms for constructing objects using inheritance are different in Grace than they are in Java and also different from how they are in Self.   

Me neither, when you put it like that. 
It is a bit ironic that Michael's withdrawn a paper from PLOP on object creation in Grace though. 
(But we can send it to EuroPlop next year, which is better to go to anyway)


> 
> By "constructor" I asume that Kim means "Grace object literal",

Yeah. We need to standardize on these names. Grace object, block & string literals aren't... literal.


> Well, I think that this desire is unreasonable: inGrace, the object literal in B.new runs before B.new exists, and certainly should do the same thing regardless of the context in which B.new is invoked.   

Right. And herein is the difficulty. 
Do you always want to inherit from a object that's already fully-formed?

> Self in that object literal has to mean the object being constructed. 

It's odd to use self to refer to an object "before [that object] B.new exists"
There is another interpretation here that makes some of these problems go away...

>> Any good examples of inheritance using mutable objects (ideally where the state has changed since it was created)?
> 
> We didn't think that this was a common use case, which is why the current spec outlaws it.   

I'm not sure it does. It says you have to be able to find the object statically, not that the object has not been mutated since construction. A no mutation rule would be very hard indeed to enforce, especially with side effects from initializers and construction code. 

> The example that I gave at the end of my original message on this topic is a great example of trying to translate a Smalltalk or Java idiom into Grace and finding that it does something different.  Here it is again:
> 
>> 
>>    def window = object  {
>>        var border = aBorder.ofColor(self.bordercolor)
>>        ...
>>        method borderColor { Color.black }
>>    }
>> 
>> 
>>    def errorWindow = object  {
>>        inherits window
>>        ...
>>        method borderColor is override { Color.red }    
>>    }
>> 
> 
> 
> My previous solution suggested that window should have a constructor that allows parameterization by color; that would indeed solve the problem,

Right.  This is my answer to Kim's question about "How do subclasses initialize defs"
they have to have an explicit constructor parameter.  There is another answer: they override them, and let the compiler sort out the dead definition. 

But - in fact - this shows Kim's problem:  If the subobject overrides the border, that will work fine, but if they jus override the borderColour it won't have any effect. 


> but part of the advantage of inheritance is to *avoid* having to parameterize by everything that might change; instead, we override it.  So, how can we make error windows have red borders without changing the declaration of window?  Like this:
> 
>    def errorWindow = object  {
>        inherits window
>        ...
>        method borderColor is override { Color.red }    
>        border.setColor( borderColor )
>    }
> 
> This seems quite natural to me.  The request border.setColor might be in practice be in an "open" method that also sets other appearance parameters, such as background color, size, etc.

The catch is that border.setColour has to be repeated in *every* subclass all the way down that wants to change the Colour.  It seems the open method heads back to having one big method with every single parameter that gets passed along. (Generalising requests might help a bit: passing through a map -Ruby style- might help a bit more)

> I think that the common cases of inheritance — where one inherits from an abstract superclass — will work just fine using Grace "delegation-style" inheritance.  This is because the abstract superclass is (in Smalltalk) just a singleton object with no state, which was our use-case when we defined Grace inheritance to clone such an object and then extend it to become the new object.

Perhaps. But if you want to do "Template Method" like things when you're setting up the object; or if you want to register it in some external service, then you can't. 

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailhost.cecs.pdx.edu/mailman/private/grace-core/attachments/20120726/34a8fb37/attachment.html>