Discuss
  • Maps and WeakMaps interoperability

Maps and WeakMaps interoperability

# David Bruant (14 years ago)

Maps [1] and WeakMaps [2] are very similar in their API. Since neither proposal discusses how they should interact with each other, I was wondering what is supposed to happen when trying to use the API of one on the other.

var m = new Map(); var key = {}; m.set(key, 37);

WeakMap.prototype.get.call(m, key); // ?

Currently Chrome canary says "illegal access". Is it the behavior that is wished for the features? My question obviously extends to Sets and any other such abstraction that would be considered in the future.

David

[1] harmony:simple_maps_and_sets [2] wiki.ecmascript.org/doku.php?id=harmony:weak_maps

# Mark S. Miller (14 years ago)

On Tue, Dec 27, 2011 at 7:15 AM, David Bruant <bruant.d at gmail.com> wrote:

Hi,

Maps [1] and WeakMaps [2] are very similar in their API. Since neither proposal discusses how they should interact with each other, I was wondering what is supposed to happen when trying to use the API of one on the other.

var m = new Map(); var key = {}; m.set(key, 37);

WeakMap.prototype.get.call(m, key); // ?

Currently Chrome canary says "illegal access". Is it the behavior that is wished for the features?

That's what I wish. JS already has name-based polymorphism (as is typical of scripting languages). Generic methods, such as those from Array.prototype, are only appropriate when the actions of the generic method can itself be fully described in terms of accessing other publicly available properties by name-based lookup. In this case, get/set/has/delete is the lowest level publicly available interface, and their semantics is defined in terms of accessing internal encapsulated properties. In this regard, they are more like the Date.prototype methods. The fact that similar operations have the same names is all the polymorphism these need or should have.

My question obviously extends to Sets and any other such abstraction that would be considered in the future.

y.

# David Bruant (14 years ago)

Le 27/12/2011 19:14, Mark S. Miller a écrit :

On Tue, Dec 27, 2011 at 7:15 AM, David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>> wrote:

Hi,

Maps [1] and WeakMaps [2] are very similar in their API. Since neither
proposal discusses how they should interact with each other, I was
wondering what is supposed to happen when trying to use the API of one
on the other.
-----
var m = new Map();
var key = {};
m.set(key, 37);

WeakMap.prototype.get.call(m, key); // ?
-----

Currently Chrome canary says "illegal access".
Is it the behavior that is wished for the features?

That's what I wish. JS already has name-based polymorphism (as is typical of scripting languages). Generic methods, such as those from Array.prototype, are only appropriate when the actions of the generic method can itself be fully described in terms of accessing other publicly available properties by name-based lookup. In this case, get/set/has/delete is the lowest level publicly available interface, and their semantics is defined in terms of accessing internal encapsulated properties. In this regard, they are more like the Date.prototype methods. The fact that similar operations have the same names is all the polymorphism these need or should have.

Very interesting point.

Currently, the Date.prototype method throw a TypeError (ES5.1 - 15.9.5 introductory section). The same is probably expected when trying map operations on weakmap (etc.) ?

# Allen Wirfs-Brock (14 years ago)

On Dec 27, 2011, at 10:29 AM, David Bruant wrote:

Le 27/12/2011 19:14, Mark S. Miller a écrit :

On Tue, Dec 27, 2011 at 7:15 AM, David Bruant <bruant.d at gmail.com> wrote: ... That's what I wish. JS already has name-based polymorphism (as is typical of scripting languages). Generic methods, such as those from Array.prototype, are only appropriate when the actions of the generic method can itself be fully described in terms of accessing other publicly available properties by name-based lookup. In this case, get/set/has/delete is the lowest level publicly available interface, and their semantics is defined in terms of accessing internal encapsulated properties. In this regard, they are more like the Date.prototype methods. The fact that similar operations have the same names is all the polymorphism these need or should have. Very interesting point.

Currently, the Date.prototype method throw a TypeError (ES5.1 - 15.9.5 introductory section). The same is probably expected when trying map operations on weakmap (etc.) ?

I think there are two separate issues here. Polymorphic application of methods and implementation inheritance via subclassing.

You would only expect polymorphic application of methods (such as in David's example) to work if the target object has an internal implementation that conforms to the expectation of the specific method that is being invoked. In most OO languages, this will frequently be the case if the target object is a "subclass" of the object that defines the method. It often will not be the case if the target object is not such a "subclass".

The date methods throw a type error in ES5.1 because they essentially requires a specific internal implementation details of instance objects and those implementation details can not be given to any other objects. Not even objects that inherit from Date.prototype or other Date instances.

For ES.next we already have a plan to modify the spec. for Date in a manner that allows "subclasses" of Date to share these date implementation details and hence allows the inherited Date.prototype instances to operate correctly on such "subclass" instances.

Given this perspective. It seems that an open question for ES.next is whether or not Map and WeakMap are "subclassable". I propose that they should be (but note that neither is a subclass of the other) and that we should take care to specify them in a manner that ensures that.

# Andreas Rossberg (14 years ago)

On 27 December 2011 16:15, David Bruant <bruant.d at gmail.com> wrote:

var m = new Map(); var key = {}; m.set(key, 37);

WeakMap.prototype.get.call(m, key); // ?

Currently Chrome canary says "illegal access".

That is a bug. It should throw TypeError.