[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