Page 1 of 1

cue init

PostPosted: Mon Apr 27, 2009 7:10 pm
by Charles
As previously described in the cues post, "cue init" will require that the first statement is "base.init" or ".init". This is currently the case except that, like C#, a "base.init" call is being added invisibly if needed. The problem I perceive with this approach is that the coder loses sight of the fact that initializers/constructors really are chained together going all the way up to Object.

For example, when a coder creates a class with 3 initializers, he should really be deciding whether each one is calling base.init or calling to the other .init's. Often one can have a single .init that calls base.init and then performs all required initialization. The other two .init's can be conveniences that call that .init. In the Objective-C community, this pattern is called "the designated initializer".

Initially, this will just be a warning, so no existing programs will break.

Again, this is the same as C# except that the call is explicit.

I hope to finish this up this week and cut a new release this Thu in time for the April update post.

Re: cue init

PostPosted: Thu Apr 30, 2009 2:06 am
by Charles
The work on "cue init" is complete and checked in. As I cleaned up the warnings from various classes, I found that it clarified some of my initializers in terms of designating one of them as the prime initializer (which then chained to base.init) and having the others call over to that one.