Re: Re: Constructors?

Hi Byron,

> I like that, and this will certainly be more comfortable to people 
> familiar with other languages that allow 'this' access in constructors. 
>  However, the compiler will need to be smart though, for example:
> 
> class A {int x;}
> new A(int y) {if (y != 0) x = 1;}
> 
> Of course the compiler would have to consider x uninitialized, but this 
> seems consistent with Nice's approach where the compiler works hard for 
> you!

Right. Note that a similar analysis is already done to check that local 
variables are set a value before they are read.


> I guess that the following would be illegal:
> 
> new A() {x = 1; println (x);}
> 
> Just as this is illegal:
> 
> new A() {this(x:1); println (x);}
> 
> It seems that after the autoconstructor is called, that 'this' is safe 
> to use.. but maybe this gets messy.

It's not safe in general to use 'this' at that point: there might be a 
subclass of A, in which case its fields are not yet initialized. That's a 
varation of the Parent/Child example. (It would be safe to access this.x in 
itself).

It would also be possible to make such construct safe by changing the 
semantics: the code after the call to this(...) would only be executed after 
the whole chain of constructors has finished (in the same way as the instance 
initilizer executes, only this time specifically to a given constructor). I'm 
not sure how often this is useful and whether this should be encouraged, 
although I do see that it would appeal to people used to Java-stlye 
constructors. Another disadvantage is that that behaviour would be rather 
complex and perhaps surprising, especially as it matters where the separation 
between construction and initialization is (and that's only clear in the 
versoin with an explicit call to this(...)). So at this point this seems more 
problematic than useful, and allowing the classical syntax for setting fields 
seems a better step.


> One aspect I like about this approach is that constructors are 
> inherited.  I've seen allot of sub classes that simply override a few 
> methods, but require all the constructors of the base class to be re 
> wrapped, in both Java and C++.

You're right, that's an additional benefit.

> Something peculiar also.  If I have the following:
> 
> class A {int x}
> new A(int x) {...do something...; this(x:x);}
> 
> your get the following error:
> Ambiguity for symbol this. Possibilities are :
> foo.C <init>(int count)
> foo.C <init>(int count)
> 
> Which is directly related to my original issue.  How do I override an 
> existing autoconstructor?

What would you want to do in "do something" ? There is already a 'new A(int 
x)' constructor, and writing one with a different behaviour seems like a 
highly confusing thing to do (for the clients of the class). You can think of 
the error message as a (bad) way to tell you that you are creating an 
ambiguity about what 'new A(x: ...)' means.

Daniel


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl