I think you should go ahead and use this idiom for these uninitializied events.
We can always change the semantics of it later, but it will be best to have the same
approach used everywhere.
On 5/15/06, Philip Romanik <[EMAIL PROTECTED]> wrote:
If the 'new' standard is to use DeclareEvent, I should go back and make
this change. Is this function supported in the Flash runtime?
Phil
> In some cases I added initial values to the object and set them to
> null. For example, many classes call events that have not been
> initialized. In addition to initializing them to null, the code now
> checks by,
>
> if (this.onload)
> this.onload.sendEvent (this);
>
>
>Hmm, in the DHTML runtime, we had started declaring undefined events on
>classes
>by using a new function, DeclareEvent, which would use a singleton dummy
>event object. But I am not sure if it's worth going back and fixing these
>to work that way or not.
>
>In LaszloCanvas.js, for example, we added
>
>DeclareEvent(LzCanvas.prototype, 'onaddsubview' );
>DeclareEvent(LzCanvas.prototype, 'onremovesubview' );
>
>The issue is that if we use this, then it costs a function call to find out
>the thing is a dummy event. Tucker had talked about hacking the compiler
>itself to special case sendEvent to do the null check first also. Anyone
>have a clear favorite policy to deal with these undeclared events?
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
