iteration order for Object

Charles Kendrick 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
>     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


More information about the es-discuss mailing list