>-----Original Message----- >From: es-discuss-boun...@mozilla.org [mailto:es-discuss- >boun...@mozilla.org] On Behalf Of Douglas Crockford >Sent: Tuesday, February 10, 2009 12:26 PM ... >There are lots of other uses for an isArray test. Since we can't fix >typeof, >Array.isArray is necessary. > >The question is how does isArray work, does it look for >[[Class]]=="Array" or >does it do something more mysterious. If we can settle on what [[Class]] >does, >then that would seem better.
No, the question is "what does it mean?" If we can decide that, we can decide how to specify it. What specific guarantees are you expecting when Array.isArray returns true? Everything specified in 15.4 excludeing 15.4.1-15.4.3 (constructor stuff)? If you want to use [[Class]]=="Array" to specify isArray and also expect to restrict host object use of [[Class]=="Array" to host objects that conform to some invariant we must specify what that invariant is. I guess it is time for one of my alternative lists. The original question was what if any restrictions should ES3.1 place upon host objects' [[Class]] values. The alternatives on the table are: 1) An implementation can give any host object any [[Class]] value it wants, including value that have specified meanings within the spec. This is what ES3 says. 2) An implementation may not use any of the specified [[Class]] values for a host object. 2a) An implementation may only use the specified [[Class]] values for a host object that is a fully conforming implement of a Section 15 object. (in which case, it is probably really a native object and not a host object at all). 3) An implementation may only use the specified [[Class]] values for host objects that conform to some specified set of invariants that ES3.1 specifies for each such [[Class]] value. #1 is what we have now with ES3 and at least some of us want to tighten the specification because it currently means when in the presence of host objects that testing [[Class]] guarantees nothing. #2 seem nice and simple to me but may not be a good fit with existing implementations and probably requires rethinking of [[Class]]=="Function" predicates in the Function.prototype.bind algorithm. #2a ultimately seem the same as #2 #3 would be fine but requires work. We would need to decide on the invariants for specified [[Class]] value. (parting shot, if [[Class]] was really called [[ToStringIdentifier]] would we even be having this conversation?) Allen _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
