On Apr 12, 2006, at 9:59 AM, P T Withington wrote:
> You'll have to upgrade your test to checking for an empty delegates
> list if we make all events always be defined (even if to the
> hypothetical 'NullEvent');
>
Of course, yes. I should have mentioned this was in lps-dev.
> On 2006-04-12, at 12:49 EDT, Jim Grandy wrote:
>
>>
>> On Apr 12, 2006, at 9:16 AM, P T Withington wrote:
>>
>>> That is what henry proposed. I mis-used the word 'created', just
>>> meaning that events would always be valid. We didn't think about
>>> making the null event really be null in swf -- maybe that is a good
>>> idea, or not, depending if newer swf runtimes will be stricter.
>>>
>> I think our assumptions about performance and behavior should not
>> be carried forward from Flash <= 8 to Flash 8.5. So having
>> sendEvent be null would most likely only be a solution for Flash
>> <= 8. (But we should benchmark and test, of course.)
>>
>> Since it's cheap to do, I'm trying as an experiment to check for
>> null every time we call sendEvent in LzView and LzNode. The biggie
>> I've seen so far is this one:
>>
>> LzNode.prototype.__LZapplyArgs = function ( args , constcall ){
>>
>> ...
>>
>> this[ a ] = args[ a ];
>> if ( !constcall ){
>> //then we need to notify the rest of the system
>> that this
>> //value changed.
>> this[ "on" + a ].sendEvent( args[ a ] );
>> }
>>
>> }
>>
>> If you don't know, __LZapplyArgs figures prominently in profile
>> traces of node/view initialization, so this is a nice find; I'll
>> measure whether it speeds anything up.
>>
>> jim
>>
>>> It is probably still valid to avoid calling send event when there
>>> are
>>> no listeners -- a future optimization.
>>>
>>> On 2006-04-12, at 12:03 EDT, Adam Wolff wrote:
>>>
>>>> I thought the plan was that we attach a singleton "NullEvent" to
>>>> declared
>>>> event slots. When a delegate registers for the event, it replaces
>>>> the null
>>>> event with a real event.
>>>>
>>>> In SWF (where call overhead is high, and it's not an error to
>>>> call a
>>>> missing function) we could define the NullEvent sendEvent method as
>>>> null
>>>> (when you're not in Debug.) In other runtimes, we can define it as
>>>> a no
>>>> op.
>>>>
>>>> This scheme *would* make it unnecessary (useless) to test for a
>>>> non-
>>>> null
>>>> slot before calling sendEvent.
>>>>
>>>> We can't afford to instantiate every event that is declared.
>>>> Much too
>>>> slow.
>>>>
>>>> A
>>>>
>>>> On Apr 12, P T Withington wrote:
>>>>
>>>>> Right, but what Henry was proposing was for their to always be an
>>>>> event object created. Then you would never have to check for the
>>>>> event object existing (so the idiom you use would go away).
>>>>>
>>>>> BUT, Jim discovered that, at least on the swf runtime, because
>>>>> function calls are relatively expensive, that testing for the
>>>>> delegateList being empty or not before calling sendEvent saved
>>>>> considerable time, at least with very frequent events (in
>>>>> particular
>>>>> onwidth and onheight).
>>>>>
>>>>> The best of all worlds would be for sendEvent to be inlined, at
>>>>> least
>>>>> to the point of checking the delegateList, and only call the
>>>>> out-of-
>>>>> line helper function when there are delegates listening. For now,
>>>>> that would have to be done by special code in the compiler...
>>>>>
>>>>> On 2006-04-12, at 00:29 EDT, Sarah Allen wrote:
>>>>>
>>>>>> In the component code and application code that I've been
>>>>>> creating,
>>>>>> it is common to write:
>>>>>> if (foo.someevent) foo.someevent.sendEvent()
>>>>>>
>>>>>> This avoids debugger warnings if no one is registered for
>>>>>> someevent.
>>>>>>
>>>>>> Sarah
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 6, 2006 at 9:01 PM, P T Withington wrote:
>>>>>>
>>>>>>> Belay that. Not sure what I was thinking here.
>>>>>>>
>>>>>>> It would be an optimization to not call sendEvent if the event's
>>>>>>> delegateList was empty. At least in the swf runtime, where
>>>>>>> function calls are costly.
>>>>>>>
>>>>>>> But I'm not sure this is the whole answer. It looks like you
>>>>>>> are
>>>>>>> trying to create some sort of 'null' event for each declaration.
>>>>>>> If you do this, you also need to check for this null event when
>>>>>>> you do add a delegate (and convert it into a real event).
>>>>>>>
>>>>>>> On 2006-04-06, at 20:38 PDT, Henry Minsky wrote:
>>>>>>>
>>>>>>>> So that needs to be a convention that everyone obeys when they
>>>>>>>> write calls
>>>>>>>> to sendEvent? Not just in the LFC, I'm just thinking about user
>>>>>>>> code, if app
>>>>>>>> developers are going to be told to do
>>>>>>>>
>>>>>>>> if (foo.someevent) foo.someevent.sendEvent()
>>>>>>>>
>>>>>>>> instead of
>>>>>>>>
>>>>>>>> foo.someevent.sendEvent()
>>>>>>>>
>>>>>>>>
>>>>>>>> Or is there some kind of magic we could use to do this
>>>>>>>> automatically ? I
>>>>>>>> guess it would need to be some kind of macro processor :-)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/6/06, P T Withington <[EMAIL PROTECTED]> wrote:
>>>>>>>>>
>>>>>>>>> If you do, annotate LPP-1915 to say this can be removed
>>>>>>>>> when all
>>>>>>>>> callers of sendEvent check for no listeners first (which
>>>>>>>>> should be
>>>>>>>>> much more efficient than making a call to the empty function).
>>>>>>>>>
>>>>>>>>> On 2006-04-06, at 19:56 PDT, Henry Minsky wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This code for declaring events is currently in the DHTML
>>>>>>>>>> runtime
>>>>>>>>>> but not in the SWF runtime.
>>>>>>>>>>
>>>>>>>>>> Should this go into the SWF runtime as is, or is there
>>>>>>>>>> anything we
>>>>>>>>>> need to do differently?
>>>>>>>>>>
>>>>>>>>>> [background for the viewing audience; we need to avoid
>>>>>>>>>> referencing
>>>>>>>>>> properties of null values
>>>>>>>>>> in the DHTML runtime, as it brings the browser javascript
>>>>>>>>>> interpreter to a screeching halt]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> LzDeclaredEvent = {};
>>>>>>>>>> LzDeclaredEvent.sendEvent = function ( a ){ return a };
>>>>>>>>>> LzDeclaredEvent.toString = function ( ){
>>>>>>>>>> return "Declared event";
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> function DeclareEvent( who , what ){
>>>>>>>>>> // debug('declare ' + who + ' what ' + what);
>>>>>>>>>> who[ what ] = LzDeclaredEvent;
>>>>>>>>>> }
>>>>>>>>>> function DeclareEvents( who , what ){
>>>>>>>>>> // debug('DeclareEvents', who, what);
>>>>>>>>>> for (var i in what) {
>>>>>>>>>> //info('what', what[i]);
>>>>>>>>>> who[what[i]] = LzDeclaredEvent;
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Henry Minsky
>>>>>>>>>> Software Architect
>>>>>>>>>> [EMAIL PROTECTED]
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Laszlo-dev mailing list
>>>>>>>>>> [email protected]
>>>>>>>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Henry Minsky
>>>>>>>> Software Architect
>>>>>>>> [EMAIL PROTECTED]
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
