Detecting the "type" of a DOM object
bruant.d at gmail.com
Mon Jun 25 11:10:32 PDT 2012
Le 25/06/2012 17:49, Allen Wirfs-Brock a écrit :
> On Jun 24, 2012, at 5:51 AM, Brendan Eich wrote:
>> David Bruant wrote:
>>> Instead of adding a new [[instanceofHint]] internal property, maybe the
>>> [[NativeBrand]] could be reused.
>> +1 on that, which suggests [[NativeBrandMatch]] instead of [[InstanceofMatch]].
> No, the whole point of transitioning from [[Class]] to [[NativeBrand]] was to ensure that [[NativeBrand]] was a closed ended, non-extensible set of specification internal nominal type tags that are used within the ES specification primarily to specify various legacy behaviors (certain built-in methods only work on specific built-in objects, etc.)
> Making [[NativeBrand]] extensible would be exactly equivalent to the current [[Class]] and would have the same issues. For example, it conflates default toString behavior with the internal nominal types.
>From the latest draft:
4) If O has a [[NativeBrand]] internal property, let tag be the
corresponding value from the Table 27.
5) Else if O is a host object, let tag be an implementation defined
string value. This value may not be "Array", "Boolean", "Date", "Error",
"Function", "JSON", "Math", "Number", "Object", "RegExp", or "String".
6) Else, let tag be the string value "Object".
Non-spec objects cannot define a [[NativeBrand]], but can have a "tag"
(which should probably be mentionned in Table 9, no?). This sounds very
subtle to me.
Also, I don't mind if a new [[InstanceOfHint]] property (that can take
any value) is added, but the difference between that and leveraging
[[NativeBrand]] (so that non-spec objects can take any value with some
exceptions) is also very subtle and I am not sure justified.
More information about the es-discuss