Hi John, you seem to be rephrasing your case without addressing my counterpoints.
So again the problem with the analogy to C is that permanently changing the definition of C so that "int" is 16 bits would damage the language, my proposal would not.
Further, I have argued in detail that it improves the language - you're addressing solely the backcompat issue as if that were the whole of the argument: it is not.
And again, I find your notion that an Object is "obviously" a HashMap very suspect. It has never been in practice; there are very large benefits to having it remain order-preserving; thousands of developers assumed the behavior would be standardized because it was so obviously useful and so consistently implemented. So it is clearly not "obvious", then, that it should be a hash map.
On 3/11/2011 11:56 AM, John Tamplin wrote:
On Fri, Mar 11, 2011 at 2:49 PM, Charles Kendrick <[email protected] <mailto:[email protected]>> wrote: Hello John, I'll assume you meant this as humor since the analogy has such obvious flaws. Having a default strategy on Object of maintaining order obviously does not preclude other strategies, nor does it damage the JavaScript language itself, as locking int to 16 bits would obviously have damaged C by requiring various new types. There is a non-zero cost of maintaining insertion order, and doing so introduces many edge cases that have been discussed. The most obvious implementation of object properties is a hash map, which does not support what you want. Aside from the technical issues, the point remains that if you write code that depends on unspecified implementation details, you should not expect that code to be portable. I think analogy with C is appropriate -- the sizes and implementation details of basic types were left unspecified, largely because specifying a particular size or representation would have made it inefficient to implement on some platforms. Sure, that meant that people had to define their own int16/int32/etc types where they cared and certainly some people wrote code assuming twos-complement or int/pointer equivalence and were surprised when the code didn't run on some other platform, but it also allowed the language to be efficiently implemented on lots of different platforms and to grow to platforms never imagined when it was first designed. -- John A. Tamplin Software Engineer (GWT), Google
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
