Re: [Bug 20019] Support subclassing ES6 Map
Map and Set are the bare collection necessities and let us avoid the hazards of using objects as maps. Beyond that, I would want to see a holistically designed collections API. Tackling equality seems important: How do value objects fit into the picture? Will there be a per-type protocol? Or an operator (or similar) that one extends? With modules and classes in ES6, we only need someone willing and able to implement such an API as an external library. As far as I’m aware, no such libraries exist. Which is surprising – IIRC several such libraries have been written for Java. Axel On Nov 21, 2012, at 13:10 , Andreas Rossberg wrote: > On 20 November 2012 21:30, Tab Atkins Jr. wrote: >> On Tue, Nov 20, 2012 at 10:57 AM, Mark S. Miller wrote: >>> I think adding a MultiMap API to ES7 is a good idea. Neither Map nor >>> MultiMap should be a subclass of the other, since neither is an LSP >>> subtype of the other. >> >> When properly designed, as long as you interact with it only through >> Map methods, a MultiMap can be an LSP subtype of Map. >> >> [...] >> >> The tricky part is dealing with .size and the iterator methods. You >> need .size to reflect the number of keys, not pairs, to be consistent >> with Map. But then .size doesn't match the length of the iterators >> returned by .items() or .values(), unless both of these are changed to >> only return the first value by default. (They can't return an array >> of values, because that's not what Map does.) > > If the multi map iterator returns the same key multiple times it > already breaks the map contract. So you would need a separate > iteration method for that. At that point, as Mark says, it is not > clear what the benefit is. > > The proper approach would be to identify a common super class that > identifies the commonalities. You could try to come up with a > hierarchy of concepts, like they did for C++0X before it got > downsized. But lacking types that hardly seems useful for JavaScript. > > /Andreas > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Bug 20019] Support subclassing ES6 Map
On 20 November 2012 21:30, Tab Atkins Jr. wrote: > On Tue, Nov 20, 2012 at 10:57 AM, Mark S. Miller wrote: >> I think adding a MultiMap API to ES7 is a good idea. Neither Map nor >> MultiMap should be a subclass of the other, since neither is an LSP >> subtype of the other. > > When properly designed, as long as you interact with it only through > Map methods, a MultiMap can be an LSP subtype of Map. > > [...] > > The tricky part is dealing with .size and the iterator methods. You > need .size to reflect the number of keys, not pairs, to be consistent > with Map. But then .size doesn't match the length of the iterators > returned by .items() or .values(), unless both of these are changed to > only return the first value by default. (They can't return an array > of values, because that's not what Map does.) If the multi map iterator returns the same key multiple times it already breaks the map contract. So you would need a separate iteration method for that. At that point, as Mark says, it is not clear what the benefit is. The proper approach would be to identify a common super class that identifies the commonalities. You could try to come up with a hierarchy of concepts, like they did for C++0X before it got downsized. But lacking types that hardly seems useful for JavaScript. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Bug 20019] Support subclassing ES6 Map
Mark S. Miller wrote: Since Map and Set will be in ES6 and MultiMap is trivially implementable from these, we can wait until we see some experimental implementations before standardizing. Hence the ES7 target. Same goes for Bag, only moreso, eh? ;-) /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Bug 20019] Support subclassing ES6 Map
On Tue, Nov 20, 2012 at 1:06 PM, Mark S. Miller wrote: > This is all very tricky and you may be able to make it work. But why? > Do you anticipate passing a multimap into a place that expects a map? > For these use cases, do you expect that the passer of the multimap > reliably intends to effectively pass only these "first" mappings per > key to the receiver? As I write this, it all seems crazy and > unreliable, and not a pattern we should encourage. Let's keep Map and > MultiMap as distinct types, and standardize only Map, WeakMap, and Set > this round. I think it's reasonable in some cases to use a MultiMap as a plain Map - for example, in URLQuery, you might not want to encode any duplicated keys. In that case, it's perfectly fine to have it act like a normal Map. However, it may be better to just let MultiMaps have a method to cast themselves into Maps. After all, there are already two distinct types of MultiMaps - ordered (Array) and unordered (Set) - the latter can't be treated as a Map since it lacks the concept of a "first" value. A more important quality is probably just being iterable, which both Map and MultiMap would have in the same way, so that may be sufficient. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Bug 20019] Support subclassing ES6 Map
On Tue, Nov 20, 2012 at 12:30 PM, Tab Atkins Jr. wrote: > On Tue, Nov 20, 2012 at 10:57 AM, Mark S. Miller wrote: >> [+es-discuss] >> >> Speaking only for myself at this point -- I do not recall MultiMap >> previously being suggested to the committee. >> >> I think adding a MultiMap API to ES7 is a good idea. Neither Map nor >> MultiMap should be a subclass of the other, since neither is an LSP >> subtype of the other. > > When properly designed, as long as you interact with it only through > Map methods, a MultiMap can be an LSP subtype of Map. > > This means that get() should grab the first value, if one exists, or > undefined otherwise, while a separate method (getAll?) returns a > (potentially empty) list of all values. set() should take only a > single value, and wipe out all other values currently attached to the > key. (Or, be n-ary and *replace* values at corresponding indexes. > Given get()'s behavior, this is behaviorally indistinguishable from a > plain Map, even if multiple values already exist on a key.) delete() > should wipe out all the values for a given key. (Plus, perhaps have a > 2-arg version which specifies a value to kill.) > > The tricky part is dealing with .size and the iterator methods. You > need .size to reflect the number of keys, not pairs, to be consistent > with Map. But then .size doesn't match the length of the iterators > returned by .items() or .values(), unless both of these are changed to > only return the first value by default. (They can't return an array > of values, because that's not what Map does.) This is all very tricky and you may be able to make it work. But why? Do you anticipate passing a multimap into a place that expects a map? For these use cases, do you expect that the passer of the multimap reliably intends to effectively pass only these "first" mappings per key to the receiver? As I write this, it all seems crazy and unreliable, and not a pattern we should encourage. Let's keep Map and MultiMap as distinct types, and standardize only Map, WeakMap, and Set this round. > >> Since Map and Set will be in ES6 and MultiMap is trivially >> implementable from these, we can wait until we see some experimental >> implementations before standardizing. Hence the ES7 target. > > Sure. It just means that we'll have legacy in the DOM already as well. > >> The issue of subclassing built-in types in general is interesting and >> important. Whatever we do for this in general, we should not need to >> make any special case for Map and MultiMap. In general, new built-in >> abstractions should act as much possible as if they were implemented >> by an ES6 class and exported by an ES6 module. (Likewise for old >> build-in abstractions, but less will likely be possible for these.) > > Agreed. > > ~TJ -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Bug 20019] Support subclassing ES6 Map
On Tue, Nov 20, 2012 at 10:57 AM, Mark S. Miller wrote: > [+es-discuss] > > Speaking only for myself at this point -- I do not recall MultiMap > previously being suggested to the committee. > > I think adding a MultiMap API to ES7 is a good idea. Neither Map nor > MultiMap should be a subclass of the other, since neither is an LSP > subtype of the other. When properly designed, as long as you interact with it only through Map methods, a MultiMap can be an LSP subtype of Map. This means that get() should grab the first value, if one exists, or undefined otherwise, while a separate method (getAll?) returns a (potentially empty) list of all values. set() should take only a single value, and wipe out all other values currently attached to the key. (Or, be n-ary and *replace* values at corresponding indexes. Given get()'s behavior, this is behaviorally indistinguishable from a plain Map, even if multiple values already exist on a key.) delete() should wipe out all the values for a given key. (Plus, perhaps have a 2-arg version which specifies a value to kill.) The tricky part is dealing with .size and the iterator methods. You need .size to reflect the number of keys, not pairs, to be consistent with Map. But then .size doesn't match the length of the iterators returned by .items() or .values(), unless both of these are changed to only return the first value by default. (They can't return an array of values, because that's not what Map does.) > Since Map and Set will be in ES6 and MultiMap is trivially > implementable from these, we can wait until we see some experimental > implementations before standardizing. Hence the ES7 target. Sure. It just means that we'll have legacy in the DOM already as well. > The issue of subclassing built-in types in general is interesting and > important. Whatever we do for this in general, we should not need to > make any special case for Map and MultiMap. In general, new built-in > abstractions should act as much possible as if they were implemented > by an ES6 class and exported by an ES6 module. (Likewise for old > build-in abstractions, but less will likely be possible for these.) Agreed. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Bug 20019] Support subclassing ES6 Map
On Tue, Nov 20, 2012 at 10:57 AM, Mark S. Miller wrote: > Since Map and Set will be in ES6 and MultiMap is trivially > implementable from these, we can wait until we see some experimental > implementations before standardizing. Hence the ES7 target. Here’s my experimental implementation, in terms of my Map shim. https://github.com/kriskowal/collections/blob/master/multi-map.js ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Bug 20019] Support subclassing ES6 Map
[+es-discuss] Speaking only for myself at this point -- I do not recall MultiMap previously being suggested to the committee. I think adding a MultiMap API to ES7 is a good idea. Neither Map nor MultiMap should be a subclass of the other, since neither is an LSP subtype of the other. Since Map and Set will be in ES6 and MultiMap is trivially implementable from these, we can wait until we see some experimental implementations before standardizing. Hence the ES7 target. The issue of subclassing built-in types in general is interesting and important. Whatever we do for this in general, we should not need to make any special case for Map and MultiMap. In general, new built-in abstractions should act as much possible as if they were implemented by an ES6 class and exported by an ES6 module. (Likewise for old build-in abstractions, but less will likely be possible for these.) On Tue, Nov 20, 2012 at 10:23 AM, wrote: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=20019 > > Tab Atkins Jr. changed: > >What|Removed |Added > > CC||jackalm...@gmail.com > > --- Comment #1 from Tab Atkins Jr. --- > Note that URLQuery isn't strictly a Map - it's a MultiMap, where one key can > map to multiple values. > > As such, we should probably check with tc39 to see if they have plans for a > MultiMap API after Maps are fully adopted, and be consistent with that. > > If they don't, we should at least make sure that the Map functions act > appropriately for a single-value Map, and have additional functions for > treating as a MultiMap (as you say, make set() take only a single value, while > add() adds more values). > > -- > You are receiving this mail because: > You are on the CC list for the bug. > -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
