[Laszlo-dev] For Review: Change 20081015-bargull-Q0K Summary: placement for contextmenus

[André Bargull]

I've recently read about try-catch performance in AS3 (sorry, I've got 
no references at hand). Basically it says, the try-block doesn't cost 
much performance, but the catch-block, so if an exception was thrown, 
made the program more than ten times slower (at least that factor, maybe 
it was even worse).


On 10/16/2008 10:53 PM, P T Withington wrote:
> My gut feel is that establishing a catch handler around each of these 
> probes would be too costly to justify the benefit.
> 
> On 2008-10-16, at 16:50EDT, Henry Minsky wrote:
> 
>> Maybe we can catch the ReferenceError in the applyArgs code in a try
>> -catch?
>>
>>
>> On Thu, Oct 16, 2008 at 4:15 PM, P T Withington <ptw at pobox.com> wrote:
>>
>>> On 2008-10-16, at 14:31EDT, André Bargull wrote:
>>>
>>> I've added "dynamic" because of two reasons:
>>>>
>>>> 1) It's needed for contextmenus to work in swf9
>>>> => the setter look-up in "LzNode#__LZapplyArgs(..)" tried to poke at
>>>> "$lzc$set_ignoreplacement", which resulted in a ReferenceError.
>>>>
>>>
>>> Rats.  I guess until we can move that part of applyArgs (determining
>>> whether or not there is a setter for an attribute) to compile-time, 
>>> we have
>>> to live with the dynamic declaration.
>>>
>>>
>>> 2) It's now possible to define contextmenus in LZX (LPP-834). Let's 
>>> say a
>>>> user defined a <contextmenu> and added an <attribute> to it. If the
>>>> contextmenu class was non-dynamic, this would result in a 
>>>> ReferenceError,
>>>> too (e.g. again at __LZapplyArgs()).
>>>>
>>>>
>>>>
>>>> On 10/16/2008 6:00 PM, P T Withington wrote:
>>>>
>>>>> On 2008-10-15, at 09:20EDT, André Bargull wrote:
>>>>>
>>>>>> Added "dynamic" modifier so setter look-up works (e.g required for
>>>>>> "ignoreplacement").
>>>>>>
>>>>> Can you explain to me more about why you need 'dynamic'?  I think 
>>>>> we want
>>>>> to minimize the use of dynamic so we can get better compile-time 
>>>>> checking.
>>>>> At least in some cases, rather than using dynamic on a class, the 
>>>>> class
>>>>> should just have a table as a property for holding whatever is 
>>>>> being stored
>>>>> dynamically on the instance.  Clearly, we'd need to check the 
>>>>> performance
>>>>> trade-off, but I think it would be safer to do things that way.
>>>>>
>>>>
>>>>
>>>
>>
>>
>> -- 
>> Henry Minsky
>> Software Architect
>> hminsky at laszlosystems.com
> 
>