[Laszlo-dev] init vs oninit vs super.init

[Benjamin Shine]

If I were Tucker, I would say, "You should never override init,  
because if you forget to call super.init(), things are deeply hosed."

(Tucker's offline for the day so we'll have to wait till tomorrow to  
have him in this discussion.)

On Aug 7, 2007, at 12:30 PM, Bret Simister wrote:

> This is about  a choice of design patterns. When extending a class  
> that needs to have new functionality during its initialization,   
> but the subclass also needs to execute the init functionality of  
> its super class, which of the methods below is the  preferred  
> design pattern?
>
> <method name="init" >
> 	super.init()
> 	...
> </method>
>
> or
>
> <handler name="oninit" >
>         ...
> </handler>
>
> and rely on the fact that when using the handler, the super.init()  
> of the class is effectively being called because it has not been  
> overridden.
>
> Even if the functionality is identical in both cases, I prefer the  
> explicit design pattern of <method name=" ..." > over the implicit  
> design pattern of <handler name="oninit" >
>
>
> my two cents,
> Bret
>
>
> On Aug 7, 2007, at 12:08 PM, Elliot Winard wrote:
>
>> Hrm.  Actually, subclass init method gets called.  Superclass init  
>> method doesn't get called unless the subclass calls superclass.init 
>> ().
>>
>> The below example is a bit misleading because brusselssprouts  
>> calls super.init() before Debug.outputting.
>> -e
>>
>>
>> ---=---===-------
>> Elliot Winard
>> Sr. Software Engineer
>> Webtop Team
>> ---=---===-------
>>
>>
>> On Tue, Aug 7, 2007 at  2:45 PM, Benjamin Shine wrote:
>>
>>> Bret and I were going through a code change and wanted a  
>>> clarification on what order things were expected to happen:
>>>
>>> <canvas>
>>> <class name="cabbage">
>>> 	<method name="init">
>>> 		// called FIRST
>>> 		Debug.write("cabbage.init (method name=init) on %w", this);
>>> 		this.setAttribute("deliciousness", 0.35);
>>> 	</method>
>>> 	<handler name="oninit">
>>> 		// called SECOND
>>> 		Debug.write("cabbage.oninit (handler name=oninit) on %w", this);
>>> 	</handler>	
>>> </class>
>>>
>>> <class name="brusselssprout" extends="cabbage">	
>>> 	<method name="init">
>>> 		super.init(); // calls method name="init" on cabbage
>>> 		Debug.write("brusselssprout.oninit method on %w,  deliciousness  
>>> is %f", this, this.deliciousness);
>>> 	</method>	
>>> 	<handler name="oninit">
>>> 		// called *after* cabbage's oninit handler
>>> 		Debug.write("brusselssprout.oninit handler on %w, deliciousness  
>>> is %f", this, this.deliciousness);
>>> 	</handler>	
>>> </class>
>>>
>>> <cabbage id="cabby" />
>>> <brusselssprout id="sprouty" />\
>>> </canvas>
>>>
>>> This produces the following output:
>>> cabbage.init (method name=init) on #cabby
>>> cabbage.oninit (handler name=oninit) on #cabby
>>> cabbage.init (method name=init) on #sprouty
>>> brusselssprout.oninit method on #sprouty,  deliciousness is 0.350000
>>> cabbage.oninit (handler name=oninit) on #sprouty
>>> brusselssprout.oninit handler on #sprouty, deliciousness is 0.350000
>>>
>>>
>>> ...which is just what I expect: superclass methods called before  
>>> sublcass methods, method name="init" called before oninit handler.
>>>
>>> Is this the guaranteed order of execution?
>>>
>>> -ben
>