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. On Fri, Sep 5, 2008 at 12:53 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote: > > Quick nits: Should probably say something about iteration capability > and what performance considerations apply there (direct methods on > JsMap for iteration, or Iterator-style interface?). Also, is this > going to be isomorphic to identity hash maps in the sense that the > hashCode/equals() of a key won't matter? > > -Ray > > On Fri, Sep 5, 2008 at 9:36 AM, Bruce Johnson <[EMAIL PROTECTED]> wrote: > > Design principles look sensible, although I'm not sure about prioritizing > > "put" over "get", since "get" happens *so* much more frequently in real > > apps. If you really want to specify something related to this, maybe you > > could refine it to, "Multiple contiguous calls to put() must be fast" > which > > could imply (in theory) some sort of lazy accumulation scheme that defers > > build a true map until the first get() is called. Just a thought. > > > > On Fri, Sep 5, 2008 at 11:57 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > >> > >> For those of you who are interested, I've started a draft collection of > >> design principles for the js map collection. However, don't feel > required > >> to read through them, as I'm going to throw together another straw man > using > >> them and send it out to the list. > >> > >> > >> On Fri, Sep 5, 2008 at 11:28 AM, BobV <[EMAIL PROTECTED]> wrote: > >>> > >>> On Fri, Sep 5, 2008 at 7:45 AM, Joel Webber <[EMAIL PROTECTED]> wrote: > >>> > 2. Can you actually use an arbitrary object as the key type? Based on > >>> > the > >>> > native put() implementation (map[key] = value), I'd guess not. I may > be > >>> > missing something, but I don't see any way to limit the key type as > >>> > it's > >>> > currently specified. > >>> > >>> If you're willing to rely on an implementation detail like this, the > >>> identity hashCode value of an object is based on a per-module counter. > >>> You could use this in web mode, and in hosted mode, just delegate to > >>> an IdentityHashMap. > >>> > >>> > >>> -- > >>> Bob Vawter > >>> Google Web Toolkit Team > >>> > >>> > >> > >> > >> > >> -- > >> "There are only 10 types of people in the world: Those who understand > >> binary, and those who don't" > >> > >> > > > > > > > > > > > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
