Re: New Set.prototype methods

[Tab Atkins Jr.]

On Sun, May 29, 2016 at 6:13 AM, Michał Wadas  wrote:
> I have written proposal for new Set.prototype methods.
>
> https://github.com/Ginden/set-methods
>
> New methods would be:
>
> Set.prototype.filter
> Set.prototype.map
> Set.prototype.some
> Set.prototype.every
> Set.prototype.find
> Set.prototype.union
> Set.prototype.intersect
> Set.isSet
>
>
> TBA:
>
> Set.prototype.difference (or .except)

Yes *please* to all of these.  I've added most of them manually to
Set.prototype on some of my projects.

One additional request in a related vein - Set.prototype.chain - like
.map, but the callback's value is iterated and added to the result
set.  (We need to coordinate this with an identical method on Array;
.chain just seems to be one of the more common names for this
operation in JS-land.)  I use this a *lot* to, for example, expand
items into related terms.

~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A plan to help TC39 become more open up to community contributions and participations

[Allen Wirfs-Brock]

I think this is a very interesting idea.  TC39 has put a lot of effort into 
community  transparency over the last decade but Ecma International (really 
most international standards organization) is organizationally not structured 
or naturally inclined to directly accept “contributions” from individual. 
Changing this within Ecma has been and will continue to be a slow and sometimes 
frustrating process.  The idea of a NFP joining Ecma as a community surrogate 
is an interacting way to approach the problem. I think it could work.

However, while the idea is simple enough the actual process of building and 
sustaining such a NFP is not so simple. Kevin Smith has already raised some 
very valid cautions about this. In particular, his cautions about the amount 
personal time required of you (or any other individuals sharing leadership 
respondability of the NFP) should not be ignored.

But, I think this really could be a viable solution if you and other organizers 
of the NFP are sufficiently motivated and committed.

I’d happy to act as an adviser as you try to get this organizers.  

Allen

PS, you might find this provides some useful background on TC39 participation: 
http://wirfs-brock.com/allen/files/papers/standpats-asianplop2016.pdf 
 


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Subclassing native class and instanceof operator

[Allen Wirfs-Brock]

> On May 31, 2016, at 3:25 AM, Logan Smyth  wrote:
> 
> The correct spec behavior is to return an instance of `MyError`. Step 7 in 
> your example is not equivalent to calling `Error` without `new`, which seems 
> to be your assumption. The `newTarget` parameter passed to `Construct` is 
> used to determine the prototype of the final object, and in this context 
> `newTarget` would be `MyError`.
> 
> Babel does not support extending builtins by default because it is difficult 
> to transpile properly and would add more boilerplate in all class cases, even 
> those which do not require logic to handle native extension. If you need 
> builtin extension support, the only way at the moment is to explicitly enable 
> it via a plugin like 
> https://www.npmjs.com/package/babel-plugin-transform-builtin-extend 
> 
> 
> On Mon, May 30, 2016 at 11:56 PM, Gray Zhang  > wrote:
> I know NodeJS outputs `true` in this case, but my problem is from the spec it 
> seems `false` is the correct result, or am I missing some chapters in spec?
> 
> Jordan Harband >于2016年5月31日周二 
> 下午2:47写道：
> In which engine did you try this? Please refer to 
> http://kangax.github.io/compat-table/es6/ 
>  under "Subclassing" to see if 
> your browser supports subclassing builtins yet.
> 
> On Mon, May 30, 2016 at 11:32 PM, Gray Zhang  > wrote:
> Recently I encountered an issue about subclassing Error and instance 
> operator, my simplified code is:
> 
> ```
> class MyError extends Error {
>   constructor() {
> super('my error’);
>   }
> }
> 
> let error = new MyError();
> console.log(error instanceof MyError);
> console.log(error.constructor);
> ```
> 
> Surprisingly the output is `false` and `function Error() { [native code] }`
> 
> I dived into the ECMAScript 2015 spec and find the behavior is correct, 
> chapter 12.3.5.1 says:
> SuperCall : super Arguments
> Let newTarget be GetNewTarget 
> ().
> If newTarget is undefined, throw a ReferenceError exception.
> Let func be GetSuperConstructor 
> ().
> ReturnIfAbrupt 
> (func).
> Let argList be ArgumentListEvaluation of Arguments.
> ReturnIfAbrupt 
> (argList).
> Let result be Construct 
> (func,
>  argList, newTarget).
> ReturnIfAbrupt 
> (result).
> Let thisER be GetThisEnvironment 
> (
>  ).
> Return thisER.BindThisValue 
> (result).
> Since Error can be called as a function without new operator, the result of 
> step 7 is an error instance rather than undefined, so this error instance 
> becomes `this` value of `thisER` and then returned as the result of new 
> MyError constructor.


Huh??  Step 7  isn’t a [[Call]] it is a [[Construct]].  Syntactic rules such as 
“must use new to invoke a constructor” can’t apply at the level of pseudo-code.

> 
> The problem is, the spec also said "The Error constructor is designed to be 
> subclassable." so I think instanceof should work correctly on subclasses, 
> however it fails now.

It is specified to work.  Your implementation must be wrong or imp complete.


> 
> This also comes to Map, Set, Array and Object constructors.

Also should work

Allen

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Subclassing native class and instanceof operator

[Logan Smyth]

The correct spec behavior is to return an instance of `MyError`. Step 7 in
your example is not equivalent to calling `Error` without `new`, which
seems to be your assumption. The `newTarget` parameter passed to
`Construct` is used to determine the prototype of the final object, and in
this context `newTarget` would be `MyError`.

Babel does not support extending builtins by default because it is
difficult to transpile properly and would add more boilerplate in all class
cases, even those which do not require logic to handle native extension. If
you need builtin extension support, the only way at the moment is to
explicitly enable it via a plugin like
https://www.npmjs.com/package/babel-plugin-transform-builtin-extend

On Mon, May 30, 2016 at 11:56 PM, Gray Zhang  wrote:

> I know NodeJS outputs `true` in this case, but my problem is from the spec
> it seems `false` is the correct result, or am I missing some chapters in
> spec?
>
> Jordan Harband 于2016年5月31日周二 下午2:47写道：
>
>> In which engine did you try this? Please refer to
>> http://kangax.github.io/compat-table/es6/ under "Subclassing" to see if
>> your browser supports subclassing builtins yet.
>>
>> On Mon, May 30, 2016 at 11:32 PM, Gray Zhang  wrote:
>>
>>> Recently I encountered an issue about subclassing Error and instance
>>> operator, my simplified code is:
>>>
>>> ```
>>> class MyError extends Error {
>>>   constructor() {
>>> super('my error');
>>>   }
>>> }
>>>
>>> let error = new MyError();
>>> console.log(error instanceof MyError);
>>> console.log(error.constructor);
>>> ```
>>>
>>> Surprisingly the output is `false` and `function Error() { [native code]
>>> }`
>>>
>>> I dived into the ECMAScript 2015 spec and find the behavior is correct,
>>> chapter 12.3.5.1 says:
>>> SuperCall : super Arguments
>>>
>>>1. Let *newTarget* be GetNewTarget
>>>
>>> 
>>>().
>>>2. If *newTarget* is *undefined*, throw a *ReferenceError* exception.
>>>3. Let *func* be GetSuperConstructor
>>>
>>> 
>>>().
>>>4. ReturnIfAbrupt
>>>
>>> 
>>>(*func*).
>>>5. Let *argList* be ArgumentListEvaluation of *Arguments*.
>>>6. ReturnIfAbrupt
>>>
>>> 
>>>(*argList*).
>>>7. Let *result* be Construct
>>>
>>>(*func*, *argList*, *newTarget*).
>>>8. ReturnIfAbrupt
>>>
>>> 
>>>(*result*).
>>>9. Let *thisER* be GetThisEnvironment
>>>
>>> (
>>>).
>>>10. Return *thisER*.BindThisValue
>>>
>>> 
>>>(*result*).
>>>
>>> Since Error can be called as a function without new operator, the result
>>> of step 7 is an error instance rather than undefined, so this error
>>> instance becomes `this` value of `thisER` and then returned as the result
>>> of new MyError constructor.
>>>
>>> The problem is, the spec also said "The Error constructor is designed to
>>> be subclassable." so I think instanceof should work correctly on
>>> subclasses, however it fails now.
>>>
>>> This also comes to Map, Set, Array and Object constructors.
>>>
>>> Babel 6.7.7 has the correct behavior which fails on instanceof operator
>>> but it really introduces some troubles, is this by design and how could I
>>> avoid such issues?
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Subclassing native class and instanceof operator

[Gray Zhang]

I know NodeJS outputs `true` in this case, but my problem is from the spec
it seems `false` is the correct result, or am I missing some chapters in
spec?

Jordan Harband 于2016年5月31日周二 下午2:47写道：

> In which engine did you try this? Please refer to
> http://kangax.github.io/compat-table/es6/ under "Subclassing" to see if
> your browser supports subclassing builtins yet.
>
> On Mon, May 30, 2016 at 11:32 PM, Gray Zhang  wrote:
>
>> Recently I encountered an issue about subclassing Error and instance
>> operator, my simplified code is:
>>
>> ```
>> class MyError extends Error {
>>   constructor() {
>> super('my error');
>>   }
>> }
>>
>> let error = new MyError();
>> console.log(error instanceof MyError);
>> console.log(error.constructor);
>> ```
>>
>> Surprisingly the output is `false` and `function Error() { [native code]
>> }`
>>
>> I dived into the ECMAScript 2015 spec and find the behavior is correct,
>> chapter 12.3.5.1 says:
>> SuperCall : super Arguments
>>
>>1. Let *newTarget* be GetNewTarget
>>
>> 
>>().
>>2. If *newTarget* is *undefined*, throw a *ReferenceError* exception.
>>3. Let *func* be GetSuperConstructor
>>
>> 
>>().
>>4. ReturnIfAbrupt
>>
>> 
>>(*func*).
>>5. Let *argList* be ArgumentListEvaluation of *Arguments*.
>>6. ReturnIfAbrupt
>>
>> 
>>(*argList*).
>>7. Let *result* be Construct
>>
>>(*func*, *argList*, *newTarget*).
>>8. ReturnIfAbrupt
>>
>> 
>>(*result*).
>>9. Let *thisER* be GetThisEnvironment
>>
>> (
>>).
>>10. Return *thisER*.BindThisValue
>>
>> 
>>(*result*).
>>
>> Since Error can be called as a function without new operator, the result
>> of step 7 is an error instance rather than undefined, so this error
>> instance becomes `this` value of `thisER` and then returned as the result
>> of new MyError constructor.
>>
>> The problem is, the spec also said "The Error constructor is designed to
>> be subclassable." so I think instanceof should work correctly on
>> subclasses, however it fails now.
>>
>> This also comes to Map, Set, Array and Object constructors.
>>
>> Babel 6.7.7 has the correct behavior which fails on instanceof operator
>> but it really introduces some troubles, is this by design and how could I
>> avoid such issues?
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Subclassing native class and instanceof operator

[Jordan Harband]

In which engine did you try this? Please refer to
http://kangax.github.io/compat-table/es6/ under "Subclassing" to see if
your browser supports subclassing builtins yet.

On Mon, May 30, 2016 at 11:32 PM, Gray Zhang  wrote:

> Recently I encountered an issue about subclassing Error and instance
> operator, my simplified code is:
>
> ```
> class MyError extends Error {
>   constructor() {
> super('my error');
>   }
> }
>
> let error = new MyError();
> console.log(error instanceof MyError);
> console.log(error.constructor);
> ```
>
> Surprisingly the output is `false` and `function Error() { [native code] }`
>
> I dived into the ECMAScript 2015 spec and find the behavior is correct,
> chapter 12.3.5.1 says:
> SuperCall : super Arguments
>
>1. Let *newTarget* be GetNewTarget
>
> 
>().
>2. If *newTarget* is *undefined*, throw a *ReferenceError* exception.
>3. Let *func* be GetSuperConstructor
>
> 
>().
>4. ReturnIfAbrupt
>
> 
>(*func*).
>5. Let *argList* be ArgumentListEvaluation of *Arguments*.
>6. ReturnIfAbrupt
>
> 
>(*argList*).
>7. Let *result* be Construct
>
>(*func*, *argList*, *newTarget*).
>8. ReturnIfAbrupt
>
> 
>(*result*).
>9. Let *thisER* be GetThisEnvironment
>
> (
>).
>10. Return *thisER*.BindThisValue
>
> 
>(*result*).
>
> Since Error can be called as a function without new operator, the result
> of step 7 is an error instance rather than undefined, so this error
> instance becomes `this` value of `thisER` and then returned as the result
> of new MyError constructor.
>
> The problem is, the spec also said "The Error constructor is designed to
> be subclassable." so I think instanceof should work correctly on
> subclasses, however it fails now.
>
> This also comes to Map, Set, Array and Object constructors.
>
> Babel 6.7.7 has the correct behavior which fails on instanceof operator
> but it really introduces some troubles, is this by design and how could I
> avoid such issues?
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Subclassing native class and instanceof operator

[Gray Zhang]

Recently I encountered an issue about subclassing Error and instance
operator, my simplified code is:

```
class MyError extends Error {
  constructor() {
super('my error');
  }
}

let error = new MyError();
console.log(error instanceof MyError);
console.log(error.constructor);
```

Surprisingly the output is `false` and `function Error() { [native code] }`

I dived into the ECMAScript 2015 spec and find the behavior is correct,
chapter 12.3.5.1 says:
SuperCall : super Arguments

   1. Let *newTarget* be GetNewTarget
   
   ().
   2. If *newTarget* is *undefined*, throw a *ReferenceError* exception.
   3. Let *func* be GetSuperConstructor
   

   ().
   4. ReturnIfAbrupt
   

   (*func*).
   5. Let *argList* be ArgumentListEvaluation of *Arguments*.
   6. ReturnIfAbrupt
   

   (*argList*).
   7. Let *result* be Construct
   
   (*func*, *argList*, *newTarget*).
   8. ReturnIfAbrupt
   

   (*result*).
   9. Let *thisER* be GetThisEnvironment
   
(
   ).
   10. Return *thisER*.BindThisValue
   
   (*result*).

Since Error can be called as a function without new operator, the result of
step 7 is an error instance rather than undefined, so this error instance
becomes `this` value of `thisER` and then returned as the result of new
MyError constructor.

The problem is, the spec also said "The Error constructor is designed to be
subclassable." so I think instanceof should work correctly on subclasses,
however it fails now.

This also comes to Map, Set, Array and Object constructors.

Babel 6.7.7 has the correct behavior which fails on instanceof operator but
it really introduces some troubles, is this by design and how could I avoid
such issues?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss