RE: ES4 draft: Map
> -Original Message-
> From: Erik Arvidsson [mailto:[EMAIL PROTECTED]
> Sent: 11. mars 2008 11:25
> To: Lars Hansen
> Cc: es4-discuss@mozilla.org
> Subject: Re: ES4 draft: Map
>
> I still find this bad UI for people that do not use types,
> and remember types are supposed to be optional.
I agree, default type parameters would be nice.
> Currently
> there is no way to create a map without providing types (not
> entirely true, see below). Neither of the following works as
> we have speced it today:
>
> var m = new Map;
> var m2 = Map();
The latter should work, thanks for catching the bug.
> the closest thing would be to do
>
> var m3 = Map({});
>
> but that is pretty ugly.
And very likely it will become illegal, since we think that class
statics will only be available on instantiated classes (unlike now,
when they are available only on uninstantiated classes), so you'd
have to write
var m3 = Map.()
or worse.
> What I would like is that the type params are optional and if
> left out treated as the any type. Another simpler option is
> to make the argument to meta::invoke to be optional and if
> left out an empty Map. is returned.
We discussed default type parameters a few times, but it was always
thrown out. I think the chief reason for that was that we always
tried to make it work in the context of Array (so that Array could be
both what it is in ES3 and something typed besides). That was a
non-starter, and rightly so.
In any case, this was the sketch we were toying with:
class Map. {
}
One issue that I remember was the question of the meaning of
an expression that names the type without parameters. For example,
if we want
new Map()
to mean
new Map.()
(and this is what you're asking for) then what do we mean when we say
simply
Map
? Do we mean to pass the uninstantiated class object around or do we
mean to instantiate it with the default parameters? The former is the
obvious interpretation, but then what about
x = Map
new x()
Does that instantiate, and so on? No doubt all these details could be
resolved, we just thought that some things should be postponed to ES5.
--lars
>
> 2008/3/11 Lars Hansen <[EMAIL PROTECTED]>:
> > Draft 3 enclosed. Changelog near the top; the only significant
> > change is fixing the bug Erik noted in the prototype get and put
> > methods.
> >
> > Please note one open issue; the current design is probably
> OK but I
> > would appreciate comments.
> >
> > --lars
> >
> >
> >
> > > -----Original Message-
> > > From: Lars Hansen
> >
> >
> > > Sent: 3. mars 2008 02:03
> > > To: Lars Hansen; es4-discuss@mozilla.org > Subject: RE:
> ES4 draft:
> > Map > > Draft 2 enclosed (changelog near the top).
> > >
> > > --lars
> > >
> > > > -Original Message-
> > > > From: [EMAIL PROTECTED] > >
> > [mailto:[EMAIL PROTECTED] On Behalf Of Lars
> Hansen > >
> > Sent: 29. februar 2008 11:34 > > To: es4-discuss@mozilla.org > >
> > Subject: ES4 draft: Map > > > > I'm enclosing the draft
> for the Map
> > class. Please comment.
> > > >
> > > > --lars
> > > >
> >
> > ___
> > Es4-discuss mailing list
> > Es4-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es4-discuss
> >
> >
>
>
>
> --
> erik
>
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Map
I still find this bad UI for people that do not use types, and
remember types are supposed to be optional. Currently there is no way
to create a map without providing types (not entirely true, see
below). Neither of the following works as we have speced it today:
var m = new Map;
var m2 = Map();
the closest thing would be to do
var m3 = Map({});
but that is pretty ugly.
What I would like is that the type params are optional and if left out
treated as the any type. Another simpler option is to make the
argument to meta::invoke to be optional and if left out an empty
Map. is returned.
2008/3/11 Lars Hansen <[EMAIL PROTECTED]>:
> Draft 3 enclosed. Changelog near the top; the only significant
> change is fixing the bug Erik noted in the prototype get
> and put methods.
>
> Please note one open issue; the current design is probably OK but
> I would appreciate comments.
>
> --lars
>
>
>
> > -Original Message-
> > From: Lars Hansen
>
>
> > Sent: 3. mars 2008 02:03
> > To: Lars Hansen; es4-discuss@mozilla.org
> > Subject: RE: ES4 draft: Map
> >
> > Draft 2 enclosed (changelog near the top).
> >
> > --lars
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen
> > > Sent: 29. februar 2008 11:34
> > > To: es4-discuss@mozilla.org
> > > Subject: ES4 draft: Map
> > >
> > > I'm enclosing the draft for the Map class. Please comment.
> > >
> > > --lars
> > >
>
> ___
> Es4-discuss mailing list
> Es4-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>
>
--
erik
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Map
Draft 3 enclosed. Changelog near the top; the only significant
change is fixing the bug Erik noted in the prototype get
and put methods.
Please note one open issue; the current design is probably OK but
I would appreciate comments.
--lars
> -Original Message-
> From: Lars Hansen
> Sent: 3. mars 2008 02:03
> To: Lars Hansen; es4-discuss@mozilla.org
> Subject: RE: ES4 draft: Map
>
> Draft 2 enclosed (changelog near the top).
>
> --lars
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen
> > Sent: 29. februar 2008 11:34
> > To: es4-discuss@mozilla.org
> > Subject: ES4 draft: Map
> >
> > I'm enclosing the draft for the Map class. Please comment.
> >
> > --lars
> >
Title: The class "Map"
The class Map
NAME: "The class 'Map'"
FILE: spec/library/Map.html
CATEGORY: Pre-defined classes (E262-3 Chapter 15)
SOURCES:REFERENCES [1], [2], [3]
SPEC AUTHOR:Lars
DRAFT STATUS: DRAFT 3 - 2008-03-11
REVIEWED AGAINST ES3: N/A
REVIEWED AGAINST ERRATA:N/A
REVIEWED AGAINST BASE DOC: N/A
REVIEWED AGAINST PROPOSALS: YES
REVIEWED AGAINST CODE: YES
REVIEWED AGAINST TICKETS: YES
IMPLEMENTATION STATUS: ES4 RI
TEST CASE STATUS: Unknown
OPEN ISSUES
* 'intrinsic::clear' uses 'iterator::get' and 'intrinsic::remove' to
perform removal. That is by design (it allows overridden methods
that observe or modify iteration and removal to work during
clearing as well). But is it desirable?
CHANGES SINCE DRAFT 2 (2008-03-03)
* The prototype 'get' and 'put' methods also accept a 'notfound'
parameter.
* Presentation:
- section headers for intrinsic methods now use the syntax
'intrinsic::foo()' instead of just 'foo'.
- compatibility note ("new in 4th edition")
- added an explicit "extends Object" clause.
- the informative method 'allElements' was renamed as 'allItems'.
- corrected a typo
- common fields in the status block above
CHANGES SINCE DRAFT 1 (2008-02-29)
* The value returned by 'hashcode' is constrained to be a number and
is always explicitly converted to uint
* Map(x) returns x if x is a Map
* 'get' and 'put' have (V|undefined) return types
* 'get' and 'put' accept an optional value (defaulting to undefined)
which is returned if the association was not found in the map
* There is a new method 'clear' to clear the map
* The object returned from helper::iterate has been annotated with
an explicit type, fixing the next field.
NOTES
* Informative methods:
Informative methods on Map do not call program-visible (i.e.,
public, protected, intrinsic, reflect, meta, iterator, or
prototype) methods on their 'this' object except as explicitly
specified in this document.
(The above clarification belongs in a general preface to the
library.)
* Subtyping for parameterized classes: We've agreed that for a
parameterized type Cls and type T, Cls. is a subtype of
Cls.<*>. That has yet to be fully formalized. The Map
class relies on that subtyping rule for its 'this' constraints on
prototype methods, and for type testing in the static
'meta::invoke' method.
REFERENCES
[1] http://wiki.ecmascript.org/doku.php?id=proposals:dictionary
[2] http://bugs.ecmascript.org/ticket/146
[3] http://bugs.ecmascript.org/ticket/203
The class Map is a parameterized, dynamic, non-final, direct
subclass of Object that provides a reliable, efficient, mutable,
and iterable map from keys to values. Keys and values may be of
arbitrary types.
COMPATIBILITY NOTE The class Map is new in the 4th Edition of this Standard.
A Map is realized as a hash table. When the Map is
constructed the caller may provide specialized functions that compare
keys and compute hash values for keys.
Synopsis
The class Map provides the following interface:
__ES4__ dynamic class Map. extends Object
{
public function Map(equals: function = (function(a,b) a === b),
hashcode: function = intrinsic::hashcode) …
static meta function invoke(object: Object): Map. …
static public const length = 2;
intrinsic function size() : uint …
intrinsic function get(key: K, notfound: (V|undefined)=undefined) : (V|undefined) …
intrinsic function put(key: K, value: V, notfound: (V|undefined)=undefined) : (V|undefined) …
intrinsic function has(key:K) : boolean …
intrinsic function remove(key:K) : boolean …
intrinsic
Re: ES4 draft: Map
How would the 'fixed' property be used, in practice? I can see a use for fixed-length vectors, but I'm unsure about vectors that can be switched between fixed and variable length by untrusted code. -Jon On 3/3/08, Lars Hansen <[EMAIL PROTECTED]> wrote: > Draft 2 enclosed (changelog near the top). > > > --lars > > > > -Original Message- > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen > > Sent: 29. februar 2008 11:34 > > To: es4-discuss@mozilla.org > > Subject: ES4 draft: Map > > > > I'm enclosing the draft for the Map class. Please comment. > > > > --lars > > > > ___ > Es4-discuss mailing list > Es4-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss > > > ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Map
Thanks, I noticed that too. Will be corrected in the next draft. --lars > -Original Message- > From: Erik Arvidsson [mailto:[EMAIL PROTECTED] > Sent: 4. mars 2008 02:42 > To: Lars Hansen > Cc: es4-discuss@mozilla.org > Subject: Re: ES4 draft: Map > > Hi Lars, > > prototype get and put are missing the new optional notfound param > > 2008/3/3 Lars Hansen <[EMAIL PROTECTED]>: > > Draft 2 enclosed (changelog near the top). > > > > --lars > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen > > > Sent: 29. februar 2008 11:34 > > > To: es4-discuss@mozilla.org > > > Subject: ES4 draft: Map > > > > > > I'm enclosing the draft for the Map class. Please comment. > > > > > > --lars > > > > > > > ___ > > Es4-discuss mailing list > > Es4-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es4-discuss > > > > > > > > -- > erik > ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Map
Hi Lars, prototype get and put are missing the new optional notfound param 2008/3/3 Lars Hansen <[EMAIL PROTECTED]>: > Draft 2 enclosed (changelog near the top). > > --lars > > > > -Original Message- > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen > > Sent: 29. februar 2008 11:34 > > To: es4-discuss@mozilla.org > > Subject: ES4 draft: Map > > > > I'm enclosing the draft for the Map class. Please comment. > > > > --lars > > > > ___ > Es4-discuss mailing list > Es4-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss > > -- erik ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Map
You missed my invisible irony mark :-P. /be On Mar 3, 2008, at 9:31 AM, P T Withington wrote: > You and Lars missed my sarcasm marks. I hope there is _not_ a > shorthand. > > On 2008-03-03, at 12:14 EST, Brendan Eich wrote: > >> We've talked about V~ for (V|undefined). It would have a few uses in >> the RI, but not enough to close the deal. >> >> /be >> >> On Mar 3, 2008, at 5:48 AM, Lars Hansen wrote: >> >>>> -Original Message- >>>> From: P T Withington [mailto:[EMAIL PROTECTED] On Behalf Of >>>> P T Withington >>>> Sent: 3. mars 2008 13:47 >>>> To: Lars Hansen >>>> Cc: Waldemar Horwat; es4-discuss@mozilla.org >>>> Subject: Re: ES4 draft: Map >>>> >>>> On 2008-03-03, at 02:26 EST, Lars Hansen wrote: >>>> >>>>> function get(key:K, default:(V|undefined)=undefined):(V| >>>>> undefined) ... >>>> >>>> If V? is shorthand for (V|null), what is the shorthand for >>>> (V|null| undefined)? Perhaps [EMAIL PROTECTED] Well, at least that >>>> expresses how I feel about a language with 'two nulls'. :P >>> >>> There is no shorthand for (V|null|undefined), though if V is >>> a nullable type then (V|undefined) works just as well. >>> >>> --lars >>> ___ >>> Es4-discuss mailing list >>> Es4-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es4-discuss >> > > ___ > Es4-discuss mailing list > Es4-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Map
You and Lars missed my sarcasm marks. I hope there is _not_ a shorthand. On 2008-03-03, at 12:14 EST, Brendan Eich wrote: > We've talked about V~ for (V|undefined). It would have a few uses in > the RI, but not enough to close the deal. > > /be > > On Mar 3, 2008, at 5:48 AM, Lars Hansen wrote: > >>> -Original Message- >>> From: P T Withington [mailto:[EMAIL PROTECTED] On Behalf Of >>> P T Withington >>> Sent: 3. mars 2008 13:47 >>> To: Lars Hansen >>> Cc: Waldemar Horwat; es4-discuss@mozilla.org >>> Subject: Re: ES4 draft: Map >>> >>> On 2008-03-03, at 02:26 EST, Lars Hansen wrote: >>> >>>> function get(key:K, default:(V|undefined)=undefined):(V| >>>> undefined) ... >>> >>> If V? is shorthand for (V|null), what is the shorthand for >>> (V|null| undefined)? Perhaps [EMAIL PROTECTED] Well, at least that >>> expresses how I feel about a language with 'two nulls'. :P >> >> There is no shorthand for (V|null|undefined), though if V is >> a nullable type then (V|undefined) works just as well. >> >> --lars >> ___ >> Es4-discuss mailing list >> Es4-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es4-discuss > ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Map
We've talked about V~ for (V|undefined). It would have a few uses in the RI, but not enough to close the deal. /be On Mar 3, 2008, at 5:48 AM, Lars Hansen wrote: >> -Original Message- >> From: P T Withington [mailto:[EMAIL PROTECTED] On Behalf Of >> P T Withington >> Sent: 3. mars 2008 13:47 >> To: Lars Hansen >> Cc: Waldemar Horwat; es4-discuss@mozilla.org >> Subject: Re: ES4 draft: Map >> >> On 2008-03-03, at 02:26 EST, Lars Hansen wrote: >> >>> function get(key:K, default:(V|undefined)=undefined):(V| >>> undefined) ... >> >> If V? is shorthand for (V|null), what is the shorthand for >> (V|null| undefined)? Perhaps [EMAIL PROTECTED] Well, at least that >> expresses how I feel about a language with 'two nulls'. :P > > There is no shorthand for (V|null|undefined), though if V is > a nullable type then (V|undefined) works just as well. > > --lars > ___ > Es4-discuss mailing list > Es4-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Map
> -Original Message- > From: P T Withington [mailto:[EMAIL PROTECTED] On Behalf Of > P T Withington > Sent: 3. mars 2008 13:47 > To: Lars Hansen > Cc: Waldemar Horwat; es4-discuss@mozilla.org > Subject: Re: ES4 draft: Map > > On 2008-03-03, at 02:26 EST, Lars Hansen wrote: > > > function get(key:K, default:(V|undefined)=undefined):(V| > > undefined) ... > > If V? is shorthand for (V|null), what is the shorthand for > (V|null| undefined)? Perhaps [EMAIL PROTECTED] Well, at least that > expresses how I feel about a language with 'two nulls'. :P There is no shorthand for (V|null|undefined), though if V is a nullable type then (V|undefined) works just as well. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Map
On 2008-03-03, at 02:26 EST, Lars Hansen wrote: > function get(key:K, default:(V|undefined)=undefined):(V| > undefined) ... If V? is shorthand for (V|null), what is the shorthand for (V|null| undefined)? Perhaps [EMAIL PROTECTED] Well, at least that expresses how I feel about a language with 'two nulls'. :P ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Map
Draft 2 enclosed (changelog near the top).
--lars
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen
> Sent: 29. februar 2008 11:34
> To: es4-discuss@mozilla.org
> Subject: ES4 draft: Map
>
> I'm enclosing the draft for the Map class. Please comment.
>
> --lars
>
Title: The class "Map"
The class Map
FILE: spec/library/Map.html
DRAFT STATUS: DRAFT 2 - 2008-03-03
IMPLEMENTATION STATUS: ES4 RI
TEST CASE STATUS: Unknown
REVIEWED AGAINST ES3: N/A
REVIEWED AGAINST ERRATA:N/A
REVIEWED AGAINST BASE DOC: N/A
REVIEWED AGAINST PROPOSALS: YES
REVIEWED AGAINST CODE: YES
CHANGES SINCE DRAFT 1
* The value returned by 'hashcode' is constrained to be a number and
is always explicitly converted to uint
* Map(x) returns x if x is a Map
* 'get' and 'put' have (V|undefined) return types
* 'get' and 'put' accept an optional value (defaulting to undefined)
which is returned if the association was not found in the map
* There is a new method 'clear' to clear the map
* The object returned from helper::iterate has been annotated with
an explicit type, fixing the next field.
NOTE ON INFORMATIVE METHODS
(This note belongs in a general preface to the library.)
Informative methods on Map do not call public or protected methods
on their this object except as explicitly specified in this
document.
OPEN ISSUES
* 'intrinsic::clear' uses 'iterator::get' and 'intrinsic::remove' to
perform removal. That is by design (it allows overridden methods
that observe or modify iteration and removal to work during
clearing as well). But is it desirable?
The class Map is a parameterized, dynamic, non-final, direct
subclass of Object that provides a reliable, efficient, mutable,
and iterable map from keys to values. Keys and values may be of
arbitrary types.
A Map is realized as a hash table. When the Map is
constructed the caller may provide specialized functions that compare
keys and compute hash values for keys.
Synopsis
The class Map provides the following interface:
__ES4__ dynamic class Map.
{
public function Map(equals: function = (function(a,b) a === b),
hashcode: function = intrinsic::hashcode) …
static meta function invoke(object: Object): Map. …
static public const length = 2;
intrinsic function size() : uint …
intrinsic function get(key: K, notfound: (V|undefined)=undefined) : (V|undefined) …
intrinsic function put(key: K, value: V, notfound: (V|undefined)=undefined) : (V|undefined) …
intrinsic function has(key:K) : boolean …
intrinsic function remove(key:K) : boolean …
intrinsic function clear() : void …
iterator function get(deep: boolean = false) : iterator::IteratorType. …
iterator function getKeys(deep: boolean = false) : iterator::IteratorType. …
iterator function getValues(deep: boolean = false) : iterator::IteratorType. …
iterator function getItems(deep: boolean = false) : iterator::IteratorType.<[K,V]> …
private const equals : function = …
private const hashcode : function = …
private var population : uint = …
}
The Map prototype object provides these direct properties:
size: function () …
get:function (key) …
put:function (key, value) …
has:function (key) …
remove: function (key) …
clear: function () …
Methods on the Map class object
new Map.( equals=…, hashcode=… )
Description The Map constructor creates a new map for key type K
and value type V.
The optional equals argument is a function that compares two
keys and returns true if they are equal and false if they are
not. This function must implement a reflexive, transitive, and
symmetric relation, and equals(k1,k2) must be constant for any two
actual keys k1 and k2. The default value for equals is a
function that compares the two keys using the === operator.
The optional hashcode argument is a function that takes a key
and returns a numeric value for it; this key is converte to a uint
hash value for the key. The hash value may be used to find
associations more quickly in the map. Two calls to hashcode on
the same key value must always result in the same hash value, and a
call to hashcode must always result in the same hash value for two
key values that compare equal by the equals function. The default
value for hashcode is the intrinsic global function hashcode.
NOTE The constraint that equals and hashcode return
constant values does not apply to key values that are not in a Map
nor referenced from an activation of any method on Map.
NOTE There is no requirement that the values returned from
hashcode for two unequal keys must be different.
NOTE The operator == is not a valid comparator for the global
intrinsic function hashcode because == will consider some
values to be equal for which hashcode returns diffe
RE: ES4 draft: Map
Following up to myself: > -Original Message- > From: Lars Hansen > Sent: 3. mars 2008 08:04 > To: 'Waldemar Horwat' > Cc: es4-discuss@mozilla.org > Subject: RE: ES4 draft: Map > > > -Original Message- > > From: Waldemar Horwat [mailto:[EMAIL PROTECTED] > > Sent: 1. mars 2008 01:53 > > > > 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. Actually, it was for Java compatibility (the API is modelled on Java, but imperfectly). No matter. > > 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. There is actually a problem with an arbitrary optional parameter, and the problem also comes up if -- as somebody sent me private mail about -- we want put() to return the previous value for the key, if there is one. For strict mode we probably would like get() to be declared to returning V or at most (V|undefined). So X would be constrained likewise. In summary, this seems reasonably simple: function get(key:K, default:(V|undefined)=undefined):(V|undefined) ... function put(key:K, value:V, default:(V|undefined)=undefined):(V|undefined) ... with the proviso that if the table may associate K with the value undefined then the programmer has to be careful and use "has". --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Map
> -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
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? > 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| 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. Should thou need this functionality, use a static method to get it. Why does get return null instead of undefined when it fails to find an instance? A version of get with a second parameter X that returns X when the value isn't present would be useful. Need a clear() method that deletes all bindings. 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. Waldemar ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Map
> -Original Message- > From: Erik Arvidsson [mailto:[EMAIL PROTECTED] > Sent: 29. februar 2008 19:17 > To: Lars Hansen > Cc: es4-discuss@mozilla.org > Subject: Re: ES4 draft: Map > > Hi Lars, > > To me it seems like iterator::get* will not return lazy > iterators. Is that intentional? I think it defeats one of > the benefits of using iterators over arrays. > > Anyway, if it is intentional, I think it should be documented > (outside the actual code). The code that is there is intentionally written so, but it does not preclude using lazy iterators. What the code specifies (and what I would welcome debate on) is that insertions into and deletions from the Map after the iterator has been obtained are not visible during iteration. A good implementation would delay creating any intermediate data structure to hold the values yet to be returned until changes to the map makes that required. But it wouldn't be appropriate for the spec to include that optimization. The requirement for helper::iterate in this regard is that it must not be observable (apart from time and space, perhaps) whether it creates intermediate data structures or not, and if it does, when it does it. (This is analogous to how the Reference data type is treated in the ES3 spec -- most implementations don't use it, even though it's all over the spec.) --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Map
Sorry that this was unclear in the meta message. The helper function
is normative in the sense that it defines the functionality, eg in the
order of operations on a data structure. But it is not visible, not
part of the api, and a real implementation does not reserve the helper
namespace. Ditto for informative functions but their prose description
gives the implementation more room for variation. --lars
On 2/29/08, Michael O'Brien <[EMAIL PROTECTED]> wrote:
> A general spec question about helper methods and the informative namespace?
>
> My presumption that both these are not part of the normative spec.
> Implementations may choose to implement the functionality without a helper
> method and without the specific informative elements. Is this correct?
>
> If so, then reading:
>
> "The iterator protocol makes use of a helper method iterate which first
> collects the values that will be returned by the iterator methods and then
> returns an object that provides the correct next method: "
>
> really means that an implementation could use the helper method iterate as
> the RI does. If not, it must provide equivalent functionality.
>
> Am I reading the meaning of helper and informative correctly?
>
> Michael
>
>
> Lars Hansen wrote:
> I'm enclosing the draft for the Map class. Please comment.
>
> --lars
>
>
>
> The class Map
> FILE: spec/library/Map.html
> DRAFT STATUS: DRAFT 1 - 2008-02-29
> IMPLEMENTATION STATUS: ES4 RI
> TEST CASE STATUS: Unknown
> REVIEWED AGAINST ES3: N/A
> REVIEWED AGAINST ERRATA:N/A
> REVIEWED AGAINST BASE DOC: N/A
> REVIEWED AGAINST PROPOSALS: YES
> REVIEWED AGAINST CODE: YES
> The class Map is a parameterized, dynamic, non-final, direct subclass of
> Object that provides a reliable, efficient, mutable, and iterable map from
> keys to values. Keys and values may be of arbitrary types.
> A Map is realized as a hash table. When the Map is constructed the caller
> may provide specialized functions that compare keys and compute hash values
> for keys.
> Synopsis
> The class Map provides the following interface:
> __ES4__ dynamic class Map.
> {
> public function Map(equals: function = (function(a,b) a === b),
> hashcode: function = intrinsic::hashcode) …
>
> static meta function invoke(object: Object): Map. …
> static public const length = 2;
>
> intrinsic function size() : uint …
> intrinsic function get(key: K) : V …
> intrinsic function put(key:K, value:V) : void …
> intrinsic function has(key:K) : boolean …
> intrinsic function remove(key:K) : boolean …
>
> iterator function get(deep: boolean = false) :
> iterator::IteratorType. …
> iterator function getKeys(deep: boolean = false) :
> iterator::IteratorType. …
> iterator function getValues(deep: boolean = false) :
> iterator::IteratorType. …
> iterator function getItems(deep: boolean = false) :
> iterator::IteratorType.<[K,V]> …
>
> private const equals : function = …
> private const hashcode : function = …
> private var population : uint = …
> }
> The Map prototype object provides these direct properties:
> size: function () …
> get:function (key) …
> put:function (key, value) …
> has:function (key) …
> remove: function (key) …
> Methods on the Map class object
> new Map.( equals=…, hashcode=… )
> Description
> The Map constructor creates a new map for key type K and value type V.
> The optional equals argument is a function that compares two keys and
> returns true if they are equal and false if they are not. This function must
> implement a reflexive, transitive, and symmetric relation, and equals(k1,k2)
> must be constant for any two actual keys k1 and k2. The default value for
> equals is a function that compares the two keys using the === operator.
> 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.
> NOTE The constraint that equals and hashcode return constant values does
> not apply to key values that are not in a Map nor referenced from an
> activation of any method on Map.
> NOTE There is no requirement that the values returned from hashcode for
> two unequal keys must be different.
> Implementation
> The Map constructor initializes the Map object by saving its parameters in
> private storage and initializing the count of the number of associations in
> the table to zero.
> public function Map(equals /*: function*/ = (function (x,y) x === y),
> hashcode /*: function*
Re: ES4 draft: Map
A general spec question about helper methods and the informative
namespace?
My presumption that both these are not part of the normative spec.
Implementations may choose to implement the functionality without a
helper method and without the specific informative elements. Is this
correct?
If so, then reading:
"The iterator protocol makes use of a helper method iterate
which first collects the values that will be returned by the iterator
methods and then returns an object that provides the correct next
method:
"
really means that an implementation could use the helper method iterate
as the RI does. If not, it must provide equivalent functionality.
Am I reading the meaning of helper and informative correctly?
Michael
Lars Hansen wrote:
I'm enclosing the draft for the Map class. Please comment.
--lars
The class "Map"
The class Map
FILE: spec/library/Map.html
DRAFT STATUS: DRAFT 1 - 2008-02-29
IMPLEMENTATION STATUS: ES4 RI
TEST CASE STATUS: Unknown
REVIEWED AGAINST ES3: N/A
REVIEWED AGAINST ERRATA:N/A
REVIEWED AGAINST BASE DOC: N/A
REVIEWED AGAINST PROPOSALS: YES
REVIEWED AGAINST CODE: YES
The class Map is a
parameterized, dynamic, non-final, direct
subclass of Object that provides a reliable, efficient,
mutable,
and iterable map from keys to values. Keys and values may be of
arbitrary types.
A Map is realized as
a hash table. When the Map is
constructed the caller may provide specialized functions that compare
keys and compute hash values for keys.
Synopsis
The class Map
provides the following interface:
__ES4__ dynamic class Map.
{
public function Map(equals: function = (function(a,b) a === b),
hashcode: function = intrinsic::hashcode) …
static meta function invoke(object: Object): Map. …
static public const length = 2;
intrinsic function size() : uint …
intrinsic function get(key: K) : V …
intrinsic function put(key:K, value:V) : void …
intrinsic function has(key:K) : boolean …
intrinsic function remove(key:K) : boolean …
iterator function get(deep: boolean = false) : iterator::IteratorType. …
iterator function getKeys(deep: boolean = false) : iterator::IteratorType. …
iterator function getValues(deep: boolean = false) : iterator::IteratorType. …
iterator function getItems(deep: boolean = false) : iterator::IteratorType.<[K,V]> …
private const equals : function = …
private const hashcode : function = …
private var population : uint = …
}
The Map prototype
object provides these direct properties:
size: function () …
get:function (key) …
put:function (key, value) …
has:function (key) …
remove: function (key) …
Methods on the Map class object
new Map.( equals=…, hashcode=… )
Description
The Map constructor
creates a new map for key type K
and value type V.
The optional equals
argument is a function that compares two
keys and returns true if they are equal and false if
they are
not. This function must implement a reflexive, transitive, and
symmetric relation, and equals(k1,k2) must be constant for any
two
actual keys k1 and k2. The default value for equals
is a
function that compares the two keys using the ===
operator.
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.
NOTE The constraint that equals and hashcode
return
constant values does not apply to key values that are not in a Map
nor referenced from an activation of any method on Map.
NOTE There is no requirement that the values
returned from
hashcode for two unequal keys must be different.
Implementation
The Map constructor
initializes the Map object by
saving its parameters in private storage and initializing the count of
the number of associations in the table to zero.
public function Map(equals /*: function*/ = (function (x,y) x === y),
hashcode /*: function*/ = intrinsic::hashcode)
: equals = equals
, hashcode = hashcode
, population = 0
{
}
FIXME (Ticket #153) The parameters to the Map
constructor should
be constrained to be function, but not any more than that
(because
that would be bad UI for scripts). Currently the RI does not support
function as a type annotation, so the current
implementation of
the constructor is unconstrained.
Map( object )
Description
When the Map class
object is called as a function, it
creates a new Map object from EnumerableId
to *,
populating the new
Re: ES4 draft: Map
Hi Lars, To me it seems like iterator::get* will not return lazy iterators. Is that intentional? I think it defeats one of the benefits of using iterators over arrays. Anyway, if it is intentional, I think it should be documented (outside the actual code). 2008/2/29 Lars Hansen <[EMAIL PROTECTED]>: > I'm enclosing the draft for the Map class. Please comment. > > --lars > > ___ > Es4-discuss mailing list > Es4-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss > > -- erik ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Map
Hello :) Ok sorry :) I'm going to search the old discussions about this in the mailing list :) EKA+ :) 2008/2/29, Lars Hansen <[EMAIL PROTECTED]>: > > > > -- > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *ekameleon > *Sent:* 29. februar 2008 11:47 > *To:* es4-discuss@mozilla.org > *Subject:* Re: ES4 draft: Map > > Hello :) > > In AS3 the flash.util.Dictionnary class contains a little argument in the > constructor to control the weak references : > > Exemple : > http://www.gskinner.com/blog/archives/2006/07/as3_dictionary.html > > In ES4 the garbage collector support weak references ? > > > No. > > This feature is really important for me :) > > > Sorry, but we've discussed this extensively in the past and have decided > not to require support for weak references in ES4. > > --lars > > > To implement a full Event model like AS3 event model based Dom2/3 W3C > event model... this feature is important for example :) > > EKA+ :) > > > > 2008/2/29, Lars Hansen <[EMAIL PROTECTED]>: > > > > I'm enclosing the draft for the Map class. Please comment. > > > > > > --lars > > > > ___ > > Es4-discuss mailing list > > Es4-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es4-discuss > > > > > > > ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Map
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ekameleon Sent: 29. februar 2008 11:47 To: es4-discuss@mozilla.org Subject: Re: ES4 draft: Map Hello :) In AS3 the flash.util.Dictionnary class contains a little argument in the constructor to control the weak references : Exemple : http://www.gskinner.com/blog/archives/2006/07/as3_dictionary.html In ES4 the garbage collector support weak references ? No. This feature is really important for me :) Sorry, but we've discussed this extensively in the past and have decided not to require support for weak references in ES4. --lars To implement a full Event model like AS3 event model based Dom2/3 W3C event model... this feature is important for example :) EKA+ :) 2008/2/29, Lars Hansen <[EMAIL PROTECTED]>: I'm enclosing the draft for the Map class. Please comment. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Map
Hello :) In AS3 the flash.util.Dictionnary class contains a little argument in the constructor to control the weak references : Exemple : http://www.gskinner.com/blog/archives/2006/07/as3_dictionary.html In ES4 the garbage collector support weak references ? This feature is really important for me :) To implement a full Event model like AS3 event model based Dom2/3 W3C event model... this feature is important for example :) EKA+ :) 2008/2/29, Lars Hansen <[EMAIL PROTECTED]>: > > I'm enclosing the draft for the Map class. Please comment. > > > --lars > > ___ > Es4-discuss mailing list > Es4-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es4-discuss > > > ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
