[cc-ing amy: new legals task below]
Ok, this is pretty funny.
If you rewrite Sarah's example in the old syntax, you will see the
same issue! This is because 'onstop' is a magic schema-defined event
and its 'type' automagically defaults to 'event'. So the example
compiles and installs the event handler 'null' onto the even onstop.
If you rewrite Sarah's example to use a non-special event name, such
as 'onfoo' it works as expected (which is to set the event initially
to null).
I have a fix that will make the event tag work correctly. Review
forthcoming.
Implementing Adam's suggestion will be necessary for Legals, so we
should add a task for that.
On 26 Jan 2006, at 14:50, Jim Grandy wrote:
On Jan 26, 2006, at 10:16 AM, P T Withington wrote:
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?
Well, I did convert the ORL and Components to use the event/handler
syntax, so I think we will have wide use :-)
I have to confess I had thought that <event name=""/> was just a
rewrite of <attribute name="" value="null"/>, but I see now that
the proposal says event would replace the idiom, not have the same
meaning.
We're up against the wire with Sage, and Henry's out of town. That
having been said, I'm uncomfortable with shipping something where
we have a bunch of useless checks for null in the code, and a bunch
of useless dispatches to empty events. Does anyone want to
volunteer to get this done ASAP?
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).
Sounds like you have a clear idea how this should work. Will you
volunteer to do it?
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
