On Dec 21, 2010, at 4:51 PM, Oliver Hunt wrote: >> But what is an array index, then? uint32 is not a type in the language. >> Would proxy[3.14] really pass a double through? > Yes, I would expect no coercion of any non-object. The reason for > disallowing objects is safety afaik, those arguments don't apply to > non-objects. > >> Array elements are named by a weird uint32 index name, with consequences on >> 'length' (but only up to 2^32 - 1 for length). I don't think passing the >> property name through uncoerced helps, unless you assume a normalizing layer >> above all name-based operations that specializes to index-names per Array's >> uint32 magic weirdness. > > And people are welcome to implement those semantics if they so desire.
If engines do not agree on whether 0xffffffff as a property name goes through a proxy get trap as a number and not a string, we have a problem. Not all engines optimize 0xffffffff to the same (uint32) value; some keep it as a string since it doesn't fit in an int32. > I just see no reason to artificially limit behaviour. The spec must prescribe exactly what is coerced and what is not, or we lose interoperation. Engines that choose to optimize id to a union of string with int32, e.g., might need to change. Some engines use tagged words still, so 31-bit signed int, not int32. It's not clear every implementor will agree. It's also not obvious why the spec must dictate implementation here if the performance has been tuned already for non-proxy classes, and the results were whatever they were (different among implementations, probably; non-standard, definitely). Why should proxies cause retuning in some value-neutral way that assumes a certain dynamic frequency of id types? This looks like over-specification. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
