jason.orendorff at gmail.com
Fri Nov 30 14:20:43 PST 2012
On Tue, Nov 27, 2012 at 12:40 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com>wrote:
> On Nov 27, 2012, at 5:07 AM, David Bruant wrote:
> >> 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
> 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 still don't care for this. It adds a level of indirection, people seem to
find it surprising, and I don't see the benefit.
Here's a counterproposal, another way to support subclassing builtins.
Suppose we introduce a method, Object.prototype.@@create, that's called
when you call Object.create(x) or new Object. It takes no arguments except
'this'; all it does is create a new object with 'this' as the [[Prototype]]:
Object.create(x) <==> x.@@create()
new C(x, y) <==> C.call(C.prototype.@@create(), x, y)
Then add Map.prototype.@@create which creates a Map with empty [[MapData]].
Likewise Set.prototype.@@create and so on.
I think the reason I don't agree with the "this is how things work for
user-defined objects" argument is that user-defined objects, by necessity,
build their functionality compositionally out of the stuff the language and
host already provide. Map and other builtin types are not like that. They
exist specifically because they can't be built from other JS parts. There
are already hundreds of such classes in the DOM.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss