[Grace-core] Semantics of object/classes

[James Noble]

> Looks good, and corresponds to the semantics I have in mind for classes.  (Again, I provided semantics for inheriting from classes as that is the case that is the most important to me.)  

right.   
I'm still wondering if Andrew can commit himself that the "unified self" is at least what we want
for _class inheritance_ - even if we get it through some other mechanism.

> Your code in "The longer story" doesn't actually execute as we don't have ";" in the language.  You would need to write 

I haven't tried executing any of that code, but I think we do have ";"! 

> def x = {
>                print "1"
>                1
>              }.apply
> 
> to get that effect.
> 
> For me, the key decision here is the one expressed in "What about side effects", that is, that the meaning of "self" is of the new object being defined.

right. 

> By the way, I get worried when I see discussions of following up the inheritance chain to execute constructor code, especially when combined with the use of "super".  It is very important that super.m be resolved statically, not dynamically like self.

the spec currently says

> In over- riding methods, method requests with the pseudo-receiver super request the prior overridden method with the given name from self. Note that no “search” is involved; super-requests can be resolved statically, unlike other method requests.

which I think is close enough to the right thing for now (feel free to make it better!)
and is what minigrace now does.

James

>  For example, if we have
> class C.new{
>       method m is public {print "C"}
> }
> 
> class D.new{
> 	inherits C.new
> 	method m is override, public {
> 		super.m
> 		print "D"
> 	}
> }
> 
> class E.new{
> 	inherits D.new
> 	method m is override, public {
> 		super.m
> 		print "E"
> 	}
> }
> 
> Now suppose we execute E.new.m.  Of course we expect it to print CDE.  However, let's take a look at what happens when E.new.m is executed:
> m (in E) executes super.m.
> This calls m in D.  It calls super.m
> 
> Now the question is what is super.m, which appears in D, but is being executed in a context where self is an object from E?
> If super were being interpreted dynamically, then it would be the m in D, resulting in an infinite loop.  Thus when we write super.m in D, it is as though we wrote C.m, while super.m in E is D.m.
> 
> We have to keep this in mind when we describe the interpretation of super, as it is easy to get this wrong.



> Kim
> 
> P.S.  Notice that all the code occurs in methods, rather than constructors, so this is a general problem, not one that depends on our interpretation of self when constructors are run.
> 
> On Aug 8, 2012, at 6:25 AM, James Noble wrote:
> 
>> On 8/08/2012, at 17:24 PM, Andrew P. Black wrote:
>> 
>>> My attempts to describe how object constructors and inheritance should work are on the Wiki:
>>> 
>>> https://projects.cecs.pdx.edu:8443/~black/NewOOL/index.cgi/wiki/ObjectConstructorDescription
>>> https://projects.cecs.pdx.edu:8443/~black/NewOOL/index.cgi/wiki/InheritanceFromObjects
>> 
>> so I shamelessly borrowed Andrew's inheritance page, and wrote up another alternative design here:
>> 
>> https://projects.cecs.pdx.edu:8443/~black/NewOOL/index.cgi/wiki/MinimalFactoryInheritance
>> 
>> this is related to my "factory method" emails, I guess, and trying to find a compromise. 
>> 
>> I don't know if this will can what Andrew wants his inheriting superclasses to do -
>> in fact, Andrew, can you send a short summary of the problem that needs fixing?
>> 
>> James
> 
>