Re: Implicit this value for getters and setters on the global object

[Claude Pache]

> Le 4 mars 2016 à 00:57, Allen Wirfs-Brock  a écrit :
> 
>> 
>> On Mar 3, 2016, at 10:57 AM, Claude Pache > > wrote:
>> 
>> Hi,
>> 
>> Consider the following test case:
>> 
>> ```html
>> 
>> 
>> function returnThisValue() { "use strict"; return this }
>> 
>> Object.defineProperties(Object.prototype, {
>> getThisValue: { value: returnThisValue, configurable: true }
>>   , thisValue: { get: returnThisValue, configurable: true }
>> })
>> 
>> window.alert(getThisValue() + "\n" + thisValue)
>> 
>> 
>> ```
>> 
>> What should be displayed? According to my tests:
>> 
>> * Firefox [1], Chrome and Edge: 
>> 
>>  undefined
>>  [object Window]
>> 
>> [1]: (For Firefox, use v.46+ in order to avoid interference with this 
>> recently-solved bug: https://bugzilla.mozilla.org/show_bug.cgi?id=603201 
>> )
>> 
>> * Safari (although I get contradictory results with further tests involving 
>> `__proto__`):
>>  
>>  undefined
>>  undefined
>> 
>> * ECMA-262, if I read correctly:
>> 
>>  undefined
>>  [object Window]
>> 
>> The relevant steps in the spec are:
>> 
>> * for `getThisArg()` : [12.3.1.4.1] step 4.b.ii, where `refEnv` is an Object 
>> Environment Record associated to the global object; 
>> `refEnv.WithBaseObject()` will be `undefined`.
>> * for `thisArg`: [8.1.1.2.6] step 5, where `bindings` is the global object 
>> and `N` is `"thisArg"`.
>> 
>> [12.3.1.4.1]: 
>> https://tc39.github.io/ecma262/#sec-function-calls-runtime-semantics-evaluation
>>  
>> 
>> [8.1.1.2.6]: 
>> https://tc39.github.io/ecma262/#sec-object-environment-records-getbindingvalue-n-s
>>  
>> 
>> 
>> Is it an intentional and/or desired behavior?
> 
> Get accessors on the global object have been defined with this behavior since 
> ES5, when accessor properties were introduced.  It was intentional that 
> global variable access has the semantics of [[Get]]/[[Set]] accesses to the 
> corresponding property of the global object.
> 
>> 
>> In practice it has an influence on what a bare `__proto__` should evaluate 
>> to.
> 
> 
> How so?  As currently specified bare `__proto__` does a get/setPrototypeOf 
> the global object that is in scope.
> 

One could want (or, at least, find logical) that the corresponding 
getter/setter receives `undefined` as its this-value, so that evaluating 
`__proto__` would throw a TypeError ("cannot convert undefined to object"). 
Just like calling `valueOf()` does.

—Claude


> 
> Allen

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

Re: Proposal: ignored arguments

[Isiah Meadows]

In my honest opinion, I don't see the benefit. Arrays are the only
structure you can even do that in. And ES3 elision elements don't exist in
strict mode.

As for unused arguments, I usually just see the normal arguments for the
interface, some of which just happen to be unused. I'd rather know what
they are regardless of if they're used, though, so it's easier to check
later on if you have to fix something. It's a little more descriptive than
`arguments[3]` (or nothing).

On Fri, Mar 4, 2016, 00:33 Dan Kaplun  wrote:

> I'd like to gauge the feasibility of a new feature, akin to ignored
> values in array destructuring
> 
> :
>
> function ignoredArgument (foo,,baz) {
>>   return foo+baz;
>> }
>> console.log(ignoredArgument(1,2,3) === 4);
>
>
>
> Which could replace this common idiom, alleviating the need for an unused
> variable:
>
> function ignoredArgument (foo,_,baz) {
>>   return foo+baz;
>> }
>> console.log(ignoredArgument(1,2,3) === 4);
>
>
>
> Does this feature make sense for a proposal? Am I missing anything?
> --
> —Dan Kaplun • dbkap...@gmail.com • 216-236-4601
> ___
> 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

Proposal: ignored arguments

[Dan Kaplun]

I'd like to gauge the feasibility of a new feature, akin to ignored values
in array destructuring

:

function ignoredArgument (foo,,baz) {
>   return foo+baz;
> }
> console.log(ignoredArgument(1,2,3) === 4);



Which could replace this common idiom, alleviating the need for an unused
variable:

function ignoredArgument (foo,_,baz) {
>   return foo+baz;
> }
> console.log(ignoredArgument(1,2,3) === 4);



Does this feature make sense for a proposal? Am I missing anything?
-- 
—Dan Kaplun • dbkap...@gmail.com • 216-236-4601
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Implicit this value for getters and setters on the global object

[Allen Wirfs-Brock]

> On Mar 3, 2016, at 10:57 AM, Claude Pache  wrote:
> 
> Hi,
> 
> Consider the following test case:
> 
> ```html
> 
> 
> function returnThisValue() { "use strict"; return this }
> 
> Object.defineProperties(Object.prototype, {
> getThisValue: { value: returnThisValue, configurable: true }
>   , thisValue: { get: returnThisValue, configurable: true }
> })
> 
> window.alert(getThisValue() + "\n" + thisValue)
> 
> 
> ```
> 
> What should be displayed? According to my tests:
> 
> * Firefox [1], Chrome and Edge: 
> 
>   undefined
>   [object Window]
> 
> [1]: (For Firefox, use v.46+ in order to avoid interference with this 
> recently-solved bug: https://bugzilla.mozilla.org/show_bug.cgi?id=603201 
> )
> 
> * Safari (although I get contradictory results with further tests involving 
> `__proto__`):
>   
>   undefined
>   undefined
> 
> * ECMA-262, if I read correctly:
> 
>   undefined
>   [object Window]
> 
> The relevant steps in the spec are:
> 
> * for `getThisArg()` : [12.3.1.4.1] step 4.b.ii, where `refEnv` is an Object 
> Environment Record associated to the global object; `refEnv.WithBaseObject()` 
> will be `undefined`.
> * for `thisArg`: [8.1.1.2.6] step 5, where `bindings` is the global object 
> and `N` is `"thisArg"`.
> 
> [12.3.1.4.1]: 
> https://tc39.github.io/ecma262/#sec-function-calls-runtime-semantics-evaluation
>  
> 
> [8.1.1.2.6]: 
> https://tc39.github.io/ecma262/#sec-object-environment-records-getbindingvalue-n-s
>  
> 
> 
> Is it an intentional and/or desired behavior?

Get accessors on the global object have been defined with this behavior since 
ES5, when accessor properties were introduced.  It was intentional that global 
variable access has the semantics of [[Get]]/[[Set]] accesses to the 
corresponding property of the global object.

> 
> In practice it has an influence on what a bare `__proto__` should evaluate to.


How so?  As currently specified bare `__proto__` does a get/setPrototypeOf the 
global object that is in scope.



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

Implicit this value for getters and setters on the global object

[Claude Pache]

Hi,

Consider the following test case:

```html


function returnThisValue() { "use strict"; return this }

Object.defineProperties(Object.prototype, {
getThisValue: { value: returnThisValue, configurable: true }
  , thisValue: { get: returnThisValue, configurable: true }
})

window.alert(getThisValue() + "\n" + thisValue)


```

What should be displayed? According to my tests:

* Firefox [1], Chrome and Edge: 

undefined
[object Window]

[1]: (For Firefox, use v.46+ in order to avoid interference with this 
recently-solved bug: https://bugzilla.mozilla.org/show_bug.cgi?id=603201 
)

* Safari (although I get contradictory results with further tests involving 
`__proto__`):

undefined
undefined

* ECMA-262, if I read correctly:

undefined
[object Window]

The relevant steps in the spec are:

* for `getThisArg()` : [12.3.1.4.1] step 4.b.ii, where `refEnv` is an Object 
Environment Record associated to the global object; `refEnv.WithBaseObject()` 
will be `undefined`.
* for `thisArg`: [8.1.1.2.6] step 5, where `bindings` is the global object and 
`N` is `"thisArg"`.

[12.3.1.4.1]: 
https://tc39.github.io/ecma262/#sec-function-calls-runtime-semantics-evaluation
[8.1.1.2.6]: 
https://tc39.github.io/ecma262/#sec-object-environment-records-getbindingvalue-n-s

Is it an intentional and/or desired behaviour?

In practice it has an influence on what a bare `__proto__` should evaluate to.

—Claude



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

Re: Callable class instances

[Claude Pache]

> Le 3 mars 2016 à 18:04, Michał Wadas  a écrit :
> 
> Are there any plans/proposals to specify user defined callable objects?
> 
> It's possible to extend Function, but it requires to specify function code as 
> string and prevents usage of local variables.
> 
> Eg:
> 
> ```
> class Foo {
> constructor() {
> this.i=0;
> }
> [Symbol.call]() {
> return class.instance.i++; // new meta property 
> } 
> } 
> const f = new Foo;
> typeof f === 'function';
> f instanceof Function === false; // most use cases would be Function 
> instances 
> f() === 0;
> f() === 1;
> f.call(null); // TypeError: undefined is not a function
> ```

The following code should work (it did for me in Chrome):

```js
class Foo {
constructor() {
let obj = () => obj.i++;
Object.setPrototypeOf(obj, new.target.prototype);
obj.i = 0;
return obj;
}
} 
```

—Claude

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

Callable class instances

[Raul-Sebastian Mihăilă]

Forgot about instanceof.

```
var x = 0;

function Foo() {
if (new.target) {
this.i = 0;
} else {
// I don't know what class.instance is supposed to mean.
return x++;
}
}

Object.setPrototypeOf(Foo, null);
Foo[Symbol.hasInstance] = () => false;
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Callable class instances

[Raul-Sebastian Mihăilă]

It seems to me that you are mixing Foo and f. If that's not intended then
what you want can be obtained with:

```
var x = 0;

function Foo() {
if (new.target) {
this.i = 0;
} else {
// I don't know what class.instance is supposed to mean.
return x++;
}
}

Object.setPrototypeOf(Foo, null);
```

All the functions that we create are user defined callable objects.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Callable class instances

[Michał Wadas]

Are there any plans/proposals to specify user defined callable objects?

It's possible to extend Function, but it requires to specify function code
as string and prevents usage of local variables.

Eg:

```
class Foo {
constructor() {
this.i=0;
}
[Symbol.call]() {
return class.instance.i++; // new meta property
}
}
const f = new Foo;
typeof f === 'function';
f instanceof Function === false; // most use cases would be Function
instances
f() === 0;
f() === 1;
f.call(null); // TypeError: undefined is not a function
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Provide hooks for Content Security Policy (CSP)?

[Mark S. Miller]

At https://github.com/tc39/ecma262/issues/450 we have started discussing
whether a discussion is warranted. Perhaps a discussion is not warranted,
in which case a thread on es-discuss is not needed, as some claim. However,
since we are now discussing this very question, the question of whether we
should have a discussion is moot. We have already started the
meta-discussion. Let's move it here to es-discuss where it belongs.

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