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.
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
