On Wed, Jan 14, 2009 at 7:08 PM, Brendan Eich <[email protected]> wrote:
> > When in doubt, use brute force. ES3 already did. Quoting from its spec for > Function.prototype.apply: > > *15.3.4.3 Function.prototype.apply (thisArg, argArray)* > [...] Otherwise, if *argArray *is neither an array nor an arguments object > (see section 10.1.8), a *TypeError *exception is thrown. If *argArray *is > either an array or an arguments object, the function is passed the > (ToUint32(*argArray*.length)) arguments *argArray*[0], *argArray*[1], …, * > argArray*[ToUint32(*argArray*.length)–1]. [...] > Yes, this is the spec text I quoted as well. But I don't understand it or your "use brute force" answer. How does Function.prototype.apply determine that argArray is an arguments object? What semantic state distinguishes it from any other array-like non-array object that inherits from Array.prototype? If an implementation is necessarily required to associate such extra semantic state in order to conform to the spec, shouldn't the spec admit that 1) at least by introducing an internal property for that purpose? After all, that's what the internal properties are for. 2) Alternatively, if its [[Class]] were "Arguments", Function.prototype.apply could test whether the [[Class]] were "Array" or "Arguments". 3) Or we could take David-Sarah's suggestion and generalize Function.prototype.apply to accept any array-like object as its second argument. We need to do something, since as it stands the operational spec is unimplementable in terms of the specified semantic state. -- Cheers, --MarkM
_______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
