[Laszlo-dev] Proposal to tweak the behavior of attributes with a setter and an initial value

André Bargull andre.bargull at udo.edu
Sat Apr 18 16:44:00 PDT 2009


On 4/19/2009 1:15 AM, P T Withington wrote:
> On 2009-04-18, at 18:59EDT, André Bargull wrote:
>>> Con:
>>>
>>> The setter code must take care checking the value of the attribute.   
>>> Since it will initially be `undefined`, referencing it as `this.foo`  
>>> will generate a warning in the swf8 runtime.  To avoid the warning,  
>>> the code must be re-written as `this['foo']`.
>>>
>>
>> That'll be for sure annoying for many people. But it's not only the
>>> reference to undefined property 'foo'
>> warning which will appear if the initial value is changed to 
>> `undefined`. Due to "implicit this" support and because it's 
>> impossible to differentiate between a property which is set to 
>> `undefined` and an `undefined` property in the swf8 runtime, also a 
>> debug-error will be generated:
>>> reference to undefined variable 'foo'
> 
> Yeah, it really stinks that this warning is based on the (incorrect) 
> `in` implementation for swf8.  I think there are two possible solutions:
> 
> 1) Make the swf8 `in` implementation a little more correct by using 
> `hasOwnProperty` to see if the property exists in the instance.  This 
> would not be perfect, but it would head off _most_ of these warnings.
> 
> 2) Use an absolutely correct test for the debug warnings.  To be 
> absolutely correct, you have to run up the prototype chain testing 
> `hasOwnProperty`.
> 
> In both cases, you look for a non-undefined value first, and only resort 
> to hasOwnProperty if that fails, so the additional overhead won't be 
> much.  I tend to lean toward solution 2.


3) Another alternative would be "Object.prototype.__resolve". 
Surprisingly __resolve understands the difference between a property set 
to undefined and an undefined property.


More information about the Laszlo-dev mailing list