[Grace-core] Semantics of object/classes

[James Noble]

Forwarding Andrew's message to Grace core since it was only sent to me!

On 9/08/2012, at 02:56 AM, Andrew P. Black wrote:

> 
> On 8 Aug 2012, at 6:25, 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. 
> 
> The problem that I see with both your description and Kim's is that they are both written interns of code mangling.  James writes, for example, that the declarations of the superclass are added to the object being constructed.  I don't want to talk to my students about code: I want total to them about objects.   That was a large part of the motivation, for me, in doing away with classes as chunks of code, and instead making them objects with a method that creates an (instance) object.
> 
> So in James' and Kim's formulations, 'Car.new' in the clause 'inherits Car.new' doesn't mean the object that car.new means everywhere else in the program: it means the chunk of code that defines car.new.   
> 
> I went to sleep last night worrying about this problem (in the sense of a dog worrying a bone) and realized that the above difference is not one of descriptive stye, abut a fundamental difference in the way that we think about, and probably teach, programming.   It's the difference that I see between Smalltalkers who really "get" oo and Java programmers who don't: the Smalltalkers talk about objects, and the Java programmers talk about code. 
> 
> So it's really important to me that we can describe inheritance in terms of objects.
> 
> This morning I thought of another compromise.  Suppose that every object has special initially (and finally) method, defined with a  special syntax
> 
> 	object {
> 		def 
> 		method ...
> 		...
> 		initially { ... }
> 		finally { ... }
> 	}
> 
> Apart from the special syntax, these are like other methods, in that they are represented in the running object, they can be called explicitly if need be, and they are inherited; a sub-object can request its super-object's initially method by writing super.initially.  What's special about them is that
> 
> 	- an object's initially method is requested automatically after the object's constructor has completed, 
> 	   but _before_ any other method is requested.
> 	- an object's finally method is requested automatically after all other method requests on an object 
> 	   have completed (i.e., in implementation terms, sometime before it's garbage collected)
> 
> I think that these will solve Kim's issue of automatically initializing the variables of a graphical object.  They are just like Smalltalk's initialize method and Java's constructors, but deal with finalization too, which we will have to address sometime.   They don't allow me to change the value of a def'd field, of course, because once a field has been def'd, it can't be changed.  Is this a big problem.
>> 
>> 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?
> 
> So let me be concrete about the problem.  I have a class aTestCase with a  constructor method class forMethod(m).  The idea is that when a programmer writes tests, she makes then parameterless methods called testxxx in a subclass of aTestCase.  So, for example, I have tried writing
> 
> class aSetTest.forMethod(m) {
>    inherits aTestCase.forMethod(m)
> 
>    var emptySet // :Set<Number>
>    var set23   // :Set<Number>
> 
>    method setup is override {
>        super.setup
>        emptySet := aSet.new
>        set23 := aSet.new
>        set23.add(2)
>        set23.add(3)
>    }
> 
>    method testEmpty is public {
>        assert (emptySet.size == 0) description ("emptySet is not empty!")
>        deny (emptySet.contains(2)) description ("emptySet contains 2!")
>    }
> 
>    method testNonEmpty is public {
>        assert(set23.size == 2)
>        assert(set23.contains(2))
>        assert(set23.contains(3))
>    }
> }
> 
> The problem is that in order to inherit from aTestCase, I MUST redefine `forMethod()`.  If I don't, I will get an instance of aTestCase, not an instance of aSetTest.   In Smalltalk I could just inherit `forMethod`; its body would say `self new` and that would generate an instance of the current self, which would be  aSetTest.   In Java, of course, I can't inherit from classes at all, so I'm just screwed.
> 
> In this example the re-definition of "forMethod" isn't terrible.  But suppose that I have four different constructor methods.  How do I inherit all of them?  I can write nested object constructors, where the classes inherit from each other in addition to the objects inheriting form each other, but I still have to make one of the constructors "primary", and write the other three in terms of the primary constructor, and then redefine the primary constructor.  So more of the implementation of the superclass shows through than it does in Smalltalk, where all of the constructors are inherited.  I suppose that in Smalltalk, the thing that I have to re-define in the subclass is the instance variable setting method, and this is perhaps the moral equivalent of the Grace constructor method.
> 
> Having some kind of "class inherits" clause would alleviate, but not solve, this problem.
> 
> 	Andrew
> 
> 
> 
> 
> 
> 
>