> -Original Message-
> From: Waldemar Horwat [mailto:[EMAIL PROTECTED]
> Sent: 1. mars 2008 01:53
> To: Lars Hansen
> Cc: es4-discuss@mozilla.org
> Subject: Re: ES4 draft: Map
>
> > The optional /hashcode/ argument is a function that takes a key and
> > returns a numeric code for it. This code may be used to find
> > associations more quickly in the map. Two calls to the /hashcode/
> > function on the same key value must return the same numeric code,
and
> > the /hashcode/ function must always return the same numeric code for
> > two objects that compare equal by the /equals/ function. The default
> > value for /hashcode/ is the intrinsic global function |hashcode|.
>
> Dost thou desire arbitrary numeric hashcodes or integral ones?
Good point. intrinsic::hashcode returns uint. Since the signature
of the Map constructor does not yet -- and probably should not, for
compatibility with scripts -- have a very constraining signature for the
hashcode argument, the most natural thing to do seems to be to require
it to return a value that can be converted to uint, and require the
implementation to convert the return value from the hashcode function
to uint. Will fix.
> > Map( object )
> >
> > When the |Map| class object is called as a function, it creates a
new
> > |Map| object from |EnumerableId| to |*|, populating the new |Map|
> > |Map| object with the own properties of /object/.
>
> Making Map(x) do something specialized like this seems like a
> bad idea. If x is already a Map, I'd expect Map(x) to be
> idempotent and return x.
This is what most built-ins in ES3 does, and we've agreed in the past to
carry the behavior forward for several of the new classes (Map, Vector,
and the primitive classes int, uint, double, decimal, string, and
boolean,
at least) but I agree that it would be more natural for Map(x) to return
x
if x is already a Map. Will fix.
> Should thou need this functionality, use a static method to get it.
We've been down that road and we rejected it.
> Why does get return null instead of undefined when it fails
> to find an instance?
No good reason that I can think of. I think undefined is at least as
sensible; will fix.
> A version of get with a second parameter X that returns X
> when the value isn't present would be useful.
I agree, and that parameter could be optional and default to
undefined. Will fix.
> Need a clear() method that deletes all bindings.
I always make a new hashtable, but sure, why not.
> The iteration protocol makes a copy before starting to
> iterate. It might be implemented via copy-on-write but I'd
> like to see how expensive this is.
See my answer to Erik, which I believe answers this.
--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
