On Nov 27, 2012, at 5:07 AM, David Bruant wrote:
> Le 27/11/2012 14:02, David Bruant a écrit :
>> Hi,
>>
>> var o = {};
>> WeakMap.call(o);
>> WeakSet.call(o);
>> Map.call(o);
>> Set.call(o);
>>
>> Currently, this works and makes o a weakmap, a weakset, a map and a set...
Sort of. They won't inherit from any of the corresponding prototype types so
none of the relevant methods will be available on those objects. However they
could be explicitly invoked on the object. If you want to make them all
available then the individual methods would have to be installed with
non-conflicting names.
But overall, why should the above be a problem? It is how ES "construction"
works and the way things work for any user defined objects. Why should
built-ins be any different?
>> I understand collections were spec'ed to enable subclassing, but I don't see
>> the value of being able to subclass this way (I think Jason Orendorff
>> already made the comment somewhere but I can't find it).
>> Would it rather make sense that instead of internal [[WeakMapData]],
>> [[MapData]], etc. each would work with a single [[CollectionData]] slot
>> which value can change depending on how it's been defined?
> Sorry, very bad working. I meant "can differ" instead of "can change". The
> idea is that [[CollectionData]] is of a certain type decide at
> initialization, but it couldn't change over time for a given object.
The [[MapData]], etc. properties are used as the "brand" that ties methods that
are dependent upon a particular internal data structure to an objet that
internally provides that data structure. If you simply replaced [[MapData]],
[[SetData]], etc with [[CollectionData]] then then you would also have to
provide another branding property for each kind of collection so the methods
don't try to operate upon the wrong kind of [[CollectionData]]
>
>> It would still be possible to subclass each (which is the minimum class
>> syntax needs since it's not possible to inherit from several things), but
>> remove the possibility to subclass several of them.
But I don't see the point, since there are no similar restrictions on user
defined "classes".
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
