cue init
Posted: Mon Apr 27, 2009 7:10 pm
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.
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.