Also, classes that overwrite init and don't call super.init()
immediately make it difficult to figure out what's going on if a
developer is looking at the superclass' init method and wondering why
things aren't init'ed properly in the subclass that they're instantiating.
i.e.
<class name="superclass">
<method name="init">
super.init();
// do something here
</method>
</class>
<class name="subclass" extends="superclass">
<method name="init">
// don't call super.init() for some reason that
// makes good sense here
</method>
</class>
<subclass>
<handler name="oninit">
// developer is confused here because
// they read the superclass init and expected
// it to be executed before code goes here.
</handler>
</subclass>
-e
P T Withington wrote:
And since I wrote that, I have to agree with Sarah. Sorry Ben!
You are correct that a general principle of OO design is that you have
to understand the method you are overriding _and_ you should always
call the super method first, unless you really know what you are
doing. But plain handlers in classes have the limitation that they
create un-overridable behavior which limits extensibility.
If you read the link Sarah sent and don't understand the reasoning,
please let me know so I can clarify.
---
Le iPhone, c'est moi.
On Aug 7, 2007, at 4:12 PM, Sarah Allen <[EMAIL PROTECTED]> wrote:
Generally, we (the Laszlo applications team) don't use events in
classes (see
http://wiki.openlaszlo.org/Best_practices#Handle_events_with_methods_in_classes)
For init this is particularly important, since if you are defining a
class, you would want an init code to run before an oninit of an
instance of that class. Therefore, it is wise to override the init
method rather than defining an event.
Sarah
On Tue, Aug 7, 2007 at 12:43 PM, Benjamin Shine wrote:
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
