On Nov 14, 2011, at 3:13 PM, Yehuda Katz wrote:
> It seems as though the spec intends to disallow host objects (i.e. DOM) from fully acting like an Array, which is clearly the intent here. Perhaps this is a time for "willful disobedience" and a correction in ES6?
Calm down -- this confrontational style is unjustified.
The spec cannot deal in non-observables. DOM host objects in most implementations are full of methods, which really are native function objects. But it's always possible to implement a work-alike. So long as a host array follows the contract in every observable way, no problem.
What's at issue is the abuse of internal methods defined only for spec-internal purposes as arbitrary "plugin APIs" by other specs. That's where negotiation and future-proofing are needed.
/be
>
> Yehuda Katz
> (ph) 718.877.1325
>
>
> On Mon, Nov 14, 2011 at 10:46 AM, Rick Waldron <waldron.rick@gmail.com> wrote:
> [snip]
>
> ES5.1 clause 8.6.2 says:
> > "The value of the [[Class]] internal property of a host object may be any String value except one of "Arguments", "Array",..."
> > In other words, host object provides (such as a DOM implementation) are not allowed to define new kinds of objects whose [[Class]] is Array.
> > It's fine to want to define a new kind of host object that is behaviorally very similar (but slight different) from instances of the built-in Array constructor. But characterizing such objects by saying they have [[Class]]=="Array"
> > is a not meaningful from a ES5.1 specification perspective.
>
> I'm fine with any formulation, as long as it gives the correct behaviour in cases like Array.prototype.concat and Array.isArray.
>
> ES 5.1 15.4.3.2 Array.isArray()
> ...
> 2. If the value of the [[Class]] internal property of arg is "Array", then return true.
> ...
>
> Considering Allen's previous comment, this is not going to be allowed.
>
> Rick
>
>
> Do you have suggestions for what to write?
>
> / Jonas
>
>