>
> Left Right,
>
> What are the benefits / disadvantages of
>
> if (collection[item] !== undefined) ...
>
> versus
>
> if (item in collection) ...
>
These are two different things. The key may exist inside the hash, but be
mapped to 'undefined', the other expression verifies whether the key exists
at all. It will have particular meaning to you, wen you serialize objects,
because the serialized version will differ, and, if you wanted to compare
hashes, for example, the comparison would fail. *sigh* ECMAScript...
OK, what I said may be harsh, but, you cannot afford this kind of mistakes
in the code that is, practically, an extension to the language...I wasn't
trying to be rude in particular towards any specific person. I rather
express my uttermost disappointment of Adobe policies with regard to how
they planned and built the framework. Sorry, I'm doing that rather too
often.
Thanks for the detailed explanation. .hasOwnProperty is used at many places
> within the Flex SDK.
>
Unfortunately, Flex SDK is not an example of a high quality code, so,
judging by how things were accomplished there is unlikely to get you good
image of AS3.
The case with toString() is slightly different - however it is defined on
Object.prototype, many classes override it, and the AVM method resolution
works in the way that it will use the toString() declared in the most
precise subclass of an Object, before it will use the toString() declared
in Object. More yet, some Flash classes, such as those that extend
EventDispatcher override toString() natively, Event-extending classes do
that too. I didn't see any framework code that would implement toString()
like so:
public const toString:Function = function(x):String { return whatever; }
so it's unlikely that any data would fall through to the "forged"
implementation (numeric classes override toString()).
yet, it's not unlikely, if you consider the situation, when someone is
trying to pass an untyped object, and later, assuming some property is a
numeric type calls toString(16). However, there's little profit for the
imaginary attacker in discovering this implementation detail... but when
someone does:
xml.user.(hasOwnProperty("@secret") && @secret)
this is likely to be exploited.
