I can see your point, but it seems more consistent that once you
declare an event you should be able to call sendEvent on it without
having to check that it is non-null first. (It is a complete mis-
feature of every C++ descendant that null is an element of every
class so you can have a runtime error even if your compiler has
proven all your type declarations.)
If you feel you have to optimize your code to not call sendEvent when
there are no listeners, you could say:
if (this.onstop.delegateList.length > 0) ...
although that is an internal interface. Perhaps we should add a
length property to events that is the number of listeners?
On 26 Jan 2006, at 00:08, Sarah Allen wrote:
I was trying to use the new event tag, and got confused, so I wrote
this simple test case:
<canvas>
<class name="foo">
<event name="onstop"/>
<method event="oninit">
Debug.write('onstop', this.onstop);
if (this.onstop) Debug.write('if (this.onstop)');
if (this.onstop == null) Debug.write('if (this.onstop ==
null)');
</method>
</class>
<foo/>
</canvas>
I had hoped that this.onstop would be null, and expected it to be
at least undefined. I was surprised by this debugger output:
onstop «¡LzEvent!#1| «foo#0».onstop»
if (this.onstop)
The currently implementation seems to be in no way equivalent to
the previous convention of:
<attribute name="onstop" value="null"/>
since it will end up always calling sendEvent when the code later
does something like:
if (this.onstop) this.onstop.sendEvent()
We started this convention just to avoid debugger warnings. This
improvement should not cause the same code to incur the cost of an
extra method call. or am I missing something?
Sarah
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
