iteration order for Object
charles at isomorphic.com
Fri Mar 11 12:11:50 PST 2011
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 <charles at isomorphic.com
> <mailto:charles at isomorphic.com>> 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
> 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
More information about the es-discuss