Good point. Jim, should this be a Sage task? Or can it be deferred
since we don't expect wide use of the event tag in the near future?
Also note that other runtimes are not forgiving when trying to get a
property of null or when calling null, so we should also
conditionalize any such optimization on the runtime (or not make it
-- which is my preference).
On 26 Jan 2006, at 11:27, Adam Wolff wrote:
I had been meaning to look into how this was implemented. When we had
talked about this in the past, I had imagined this kind of
implementation:
For a declared event onfoo, the declaration sets the onfoo slot to a
single shared null event, comething like this:
Myclass.prototype.onfoo = LzSharedNullEventSingleton;
That thing has a declaration that looks in part like this:
LzSharedNullEventSingleton = {};
LzSharedNullEventSingleton.sendEvent = function (){}
//if it helps performance, use if ( $debug ) to make the slot null
//when the debugger is turned off
Since delegates are responsible for creating events, we change the
register code to look in part like this:
LzDelegate.prototype.register = function ( eventSender , eventName){
...
var anEvent = eventSender[ eventName ];
if ( anEvent == LzSharedNullEventSingleton ){
anEvent = { delegateList : [ this ] ,
__proto__ : _root.LzEvent.prototype };
eventSender[ eventName ] = anEvent;
}
...
I would expect that when we go to declare all of the LFC events,
something
like this will be necessary.
A
On Jan 26, P T Withington wrote:
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
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
