[Grace-core] Summer Plans

[Kim Bruce]

Yeah, there are problems with defs, though it works fine for variables (I hadn't tried it for defs, and it doesn't work with the current implementation).  Overriding it would be fine because nothing is private and would always be accessible in the subclass, though one would expect you would always call super.setUp at the start.

Again, my main issue is not polluting the namespace with temporary identifiers, and the object-solution doesn't help with that.

I'm also beginning to think we will need "private" even though I'd hoped we might not need it.

Kim



On Jun 19, 2012, at 4:15 PM, Andrew P. Black wrote:

> 
> On 19 Jun 2012, at 14:19 , Kim Bruce wrote:
> 
>> My preferred solution at the moment would be:
>> 
>> 	class aRectangle.at (center: Location) width (w:Number) height (h:Number) -> ShapeType {
>> 		def topLeft
>> 	        def bottomRight
>> 		method setUp {       // confidential  -- perhaps put at the end of the class def
>>  			def diagonal = w at h
>> 			def semiDiagonal = diagonal / 2
>> 			topLeft = center - semiDiagonal
>> 			bottomRight = center + semiDiagonal
>>               }
>> 
>> 		setUp  // execute the method
>> 		method ...
>> 		method ...
>> 					...
>> 	}
> 
> 
> I don't like this approach, because it re-introduces all of the problems with object initialization that we solved when we invented object constructors.  Specifically, if setUp is a method, then initialization of this object can be broken by overriding setUp in a superObject.  Or can it?  
> Well, that depends on whether we have different rules for method requests that occur before the requestor exists, which I suppose we must have, because your setUp method "assigns" to defined names ...  that's three more language constructs you just added.
> 
> (1) defs without values
> (2) delayed binding of def'd names using =
> (3) "methods" that can only be requested on self, and only before self has been created.  
> 
> Actually, setUp should be private (= lexically-bound), not confidential, and reading the Encapsulation paper again, I am inclined to think that we may need that.   If we don't have it, then this "pollutes the namespace" of methods, which is far worse than polluting that of fields, since methods are externally visible, and I don't think that (by default) fields should be.
> 
> 	Andrew
>