On Fri, Sep 5, 2008 at 1:14 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> Iteration is an interesting question I was planning to punt on until the
> design was more stable, as I don't believe we can truly answer that question
> without having the basic implementation nailed down.
>
> I don't think it's one-to-one comparable with either identity or normal
> equality maps, as the definition of when two keys are equal will solely rely
> on the underlying JavaScript interpretation of the keys, and that will be
> done using the fastest semantics we can get. So for strings it is equality
> based, as that is how the underlying JavaScript API treats their strings,
> but for user class objects it will be identity based, as the fastest way for
> us to index them is via a extended property added to the object.
>
I guess for me the big question is what is trying to be accomplished here.
With overlay types, it is pretty trivial to get "bare metal" JS maps, so it
seems that this should be something more, with abstractions to make it more
"Java-like" while not adding things which make it inefficient. I think it
might be worthwhile to preserve Java equality semantics here by using the
hash code as the key into the JS map, and managing collisions there.
Something like:
map = {hash1: [obj1, obj2, obj3], hash2: [obj4], hash3: [obj5, obj6]}
That also gets you away from worring about keys colliding on different (or
future) browsers, and you preserve Java equality semantics. Lookup should
still be O(1) since hopefully collisions are rare, iteration is quick, etc.
If a hash function is slow, it would be up to the hash function writer to
cache the result in the object as is already best practice, rather than the
Map implementation doing that automatically for them.
One other suggestion -- I think rather than optimizing lots of puts in a row
you want to allow a JSO to be passed to initialize the map. From my
experience, simply having all the put calls is slow and takes up more space
in the generated JS -- the primary way I improved NumberFormat's startup
performance was by simply building a JSO directly with the data I needed
rather than doing a bunch of puts into a map. So, for the users that will
care abouot this, I think passing in a JSO to initialize the map will be a
better choice.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
