[Grace-core] Constructors

James Noble kjx at ecs.vuw.ac.nz
Fri Oct 29 16:53:19 PDT 2010


> I'd rather NOT call them with a normal send, because that leads to  
> the problems below.

The aim of calling with a normal send is that e.g. factory methods,  
flyweights etc
can be programmed by customising the "class" or "factory" object that  
the class
declaration generates at runtime.  (If that's the way we go*).  Having  
a different
kind of send seems to be getting too close to Java's static methods  
(which we don't want).

>> * But then how do constructor call other constructors? To which  
>> object are constructor
>>   calls (and self calls) sent?
>
> In "new Capacity(...)", the "new" allocates the space, while the  
> constructor body initializes the object.

right. So this isn't really a message send, is it?
Or is it syntactic sugar for Capacity.new(...)

>  This makes calls of superconstructors easy, as we just call them by  
> name (without the "new") as I wrote in my code.

Right.. So that bit I like, I think.
Inside a constructor (or an initialiser or a maker or whatever)
"self" is bound to the class metaobject, or factory object, or  
whatever -
and so (implicit) self sends can call another constructor directly.

Then, you're right: how does the object actually get allocated?

So I can see the advantage of "new" there.

>  If we had to resort to calling them the same way as methods then it  
> would somehow have to know when to allocate space and when not to.

Yep.  Andrew: how does your Emerald encoding cope with this issue?

> Moreover this has the advantage of working the way that other  
> languages they are familiar with work.

right. and this is important.

>> * how do the calls to "classes"/"factories" work with **type  
>> parameters**?
>
> Just the way that I (and you) wrote them.  Put them in pointy  
> brackets.
>
> Am I missing something?

Well we're putting those pointy brackets on functions - how do they  
work,
particularly in dynamically typed code?

J 


More information about the Grace-core mailing list