A strawman for subclassing

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Jun 14 09:30:11 PDT 2011

At a meta-level, I think we meed to be careful of  our terminology here.  

What <| does is create an instance of its RHS that is in all ways identical to the original  RHS except for the values of its [[Prototype]] internal property.  This includes internal properties such as [[Class]].  For example, myProto <| [1,2,3], creates an object that still has a [[Class]] value of "Array".  I don't think it is particularly accurate to think of this object as being an instance of a "subclass" of Array.  The <| proposal suggests that <| should be called "prototype for".  If we are going to have an explicit class declaration, I think we should reserve the term "subclass" for the specialization semantics defined by that construct.

On Jun 13, 2011, at 5:08 PM, David Bruant wrote:

> Le 14/06/2011 01:24, Allen Wirfs-Brock a écrit :
>> On Jun 13, 2011, at 3:46 PM, David Bruant wrote:
>>> Hi,
>>> The subclassing native constructor issue came out several times on the
>>> list and on the web. However, I do not see a strawman for this. There
>>> are strawman:array_create and strawman:array_subtypes, but no mention of
>>> a generic solution.
>> The <| operator is the proposed solution.
> Oh ok, sorry, I hadn't read it yet. Thanks.
>> Using <|  instances with arbitrary [[Prototype]] values can be created for any type built-in object type that has a literal representation.  that is functions, arrays, regexps, and less interestingly, strings, numbers, booleans.  The resulting instance all have the appropriate special internal behaviors that are associated with the built-in types.
> It requires the right-hand side to have a specific initialization
> syntax. It currently works for all the "classes" you cited ("functions,
> arrays, regexps, and less interestingly, strings, numbers, booleans"),

I'd be very careful about using the term "classes" to describe these kinds of built-on objects. There distinguishing characteristics are all extra-lingual behaviors that can't be specified via the class declarations as currently proposed.

> but does not for the current harmony:simple_maps_and_sets for which
> there is currently no specific syntax.

Good point. 

If the current specification of Map and Set in the proposal is taken as normative then they can be subclassed simply by:
  class MyMap extends Map {
     constructor () {super()}

This should work because there is nothing in the definition of Map that depends upon any new or modified [[ ]] internal behaviors or state.  This would still be true even if get/has/set/delete have native implementations which they undoubtably would in order to avoid linear lookup.  There only real dependency is upon the private instance variables keys and vals and the proposed subclassing mechanism would handle that.

> Consequently, these could not be
> subclassed (or I am missing something).
> This would be the case for any other native "class" that wouldn't such
> syntax. I'm not sure it's is viable in the long term because it will
> require all subclassable (something people will want to subclass)
> "classes" to have a syntax.
> I like the idea of the <| operator, but a generic non-syntaxy solution
> would be good too in my opinion. It would also allow people to subclass
> host constructors (host objects with [[Construct]]).

As currently specified it isn't really possible to say what would or wouldn't work with host objects.  For example, host object aren't even required to may attention to the value of [[Prototype]].  The bigger issue that is lurking is what does it mean to subclass a Proxy. They are the ES.next equivalent of host objects.


More information about the es-discuss mailing list