A strawman for subclassing

David Bruant david.bruant at labri.fr
Wed Jun 15 07:36:35 PDT 2011

Le 14/06/2011 18:30, Allen Wirfs-Brock a écrit :
> 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.
You're right, I've been a little light on my terminology.

> On Jun 13, 2011, at 5:08 PM, David Bruant wrote:
>> 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.
I think I am missing something. Why are objects with modified internal 
[[]] methods forbidden with class inheritance mechanism?

>> 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.
Indeed. Shouldn't a class mechanism capture these (host constructors and 
function proxies) as well right away or is there a particular urge 
justifying not doing so by ES.next release?


More information about the es-discuss mailing list