On 6/13/14, 6:33 AM, Tom Van Cutsem wrote:
> As Allen mentioned, this came up a number of times in TC39 meetings and
> I believe the fear for exotic objects that require control over
> [[Construct]] was the biggest show-stopper. If more knowledgeable people
> like Boris can vouch for the fact that this isn't the case, that would
> remove the biggest roadblock.

The basic question is how that affects what WebIDL needs here is how it 
should play with subclassing.

If we don't care about subclassing WebIDL objects, there is no issue: 
WebIDL can just override [[Call]] as it does right now and we move on 
with life.  Note that some implementations at the moment override 
[[Construct]], not [[Call]] and just throw from [[Call]], so as to 
preclude web pages from relying on the current spec's [[Call]] behavior, 
since that would presumably interact badly with trying to introduce 
subclassing.

If we do care about subclassing, then presumably the "construct the 
right sort of object" and "initialize it" actions need to be somewhat 
decoupled for these objects.  It seems to me that both Allen's current 
spec and Jason's proposal accomplish that, right?

In Jason's proposal it would look like this, if I understand it right:

   subclass[Symbol.new] = function(...args) {
     // Modify args as desired.
     var obj = superclass[Symbol.new](...args);
     // Modify obj as desired.
     return obj;
   }

which is pretty similar to how this would be done without classes:

   function subclass(...args) {
     // Assume that we're being invoked via new.
     // Modify args as desired.
     var obj = new superclass(...args);
     // Modify obj as desired.
     return obj;
   }

except there is nothing that needs to be done if you don't want to munge 
args or obj, since not defining Symbol.new on the subclass will simply 
find it on the superclass.

In Allen's spec, it would look like this:

   "subclass constructor": function(...args) {
     // "this" is already set to the right object that got created via
     // looking up Symbol.create and calling it.
     // Modify args as desired.
     superclass.apply(this, ...args);
     // Modify "this" as desired.
   }

Is my understanding of the Allen and Jason's proposals correct?  I'd 
like to avoid making any claims of how these interact with WebIDL until 
I'm sure I'm not missing something important.

-Boris

On 6/13/14, 6:33 AM, Tom Van Cutsem wrote:
> As Allen mentioned, this came up a number of times in TC39 meetings and
> I believe the fear for exotic objects that require control over
> [[Construct]] was the biggest show-stopper. If more knowledgeable people
> like Boris can vouch for the fact that this isn't the case, that would
> remove the biggest roadblock.

The basic question is how that affects what WebIDL needs here is how it 
should play with subclassing.

If we don't care about subclassing WebIDL objects, there is no issue: 
WebIDL can just override [[Call]] as it does right now and we move on 
with life.  Note that some implementations at the moment override 
[[Construct]], not [[Call]] and just throw from [[Call]], so as to 
preclude web pages from relying on the current spec's [[Call]] behavior, 
since that would presumably interact badly with trying to introduce 
subclassing.

If we do care about subclassing, then presumably the "construct the 
right sort of object" and "initialize it" actions need to be somewhat 
decoupled for these objects.  It seems to me that both Allen's current 
spec and Jason's proposal accomplish that, right?

In Jason's proposal it would look like this, if I understand it right:

```js
   subclass[Symbol.new] = function(...args) {
     // Modify args as desired.
     var obj = superclass[Symbol.new](...args);
     // Modify obj as desired.
     return obj;
   }
```

which is pretty similar to how this would be done without classes:

```js
   function subclass(...args) {
     // Assume that we're being invoked via new.
     // Modify args as desired.
     var obj = new superclass(...args);
     // Modify obj as desired.
     return obj;
   }
```

except there is nothing that needs to be done if you don't want to munge 
args or obj, since not defining Symbol.new on the subclass will simply 
find it on the superclass.

In Allen's spec, it would look like this:

```js
   "subclass constructor": function(...args) {
     // "this" is already set to the right object that got created via
     // looking up Symbol.create and calling it.
     // Modify args as desired.
     superclass.apply(this, ...args);
     // Modify "this" as desired.
   }
```

Is my understanding of the Allen and Jason's proposals correct?  I'd 
like to avoid making any claims of how these interact with WebIDL until 
I'm sure I'm not missing something important.