Re: name anonymous functions on property assignments
Indeed, but my linting rules forbid using the comma operator :-)
On Sat, Jan 28, 2017 at 11:17 AM, Oriol _
wrote:
> > I fixed it by putting the function inside `Object()`
>
> You can also use the comma operator:
>
> ```js
> var anon = (0, function () {});
> anon.name; // ""
> ```
>
> ;Oriol
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: name anonymous functions on property assignments
> I fixed it by putting the function inside `Object()`
You can also use the comma operator:
```js
var anon = (0, function () {});
anon.name; // ""
```
;Oriol
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: name anonymous functions on property assignments
In `var anon = function () {};`, I was relying on `anon.name` being the
empty string. One of the packages this matters in is
https://www.npmjs.com/package/function.prototype.name, which attempts to
polyfill function names in IE. I fixed it by putting the function inside
`Object()`
https://github.com/ljharb/function.prototype.name/blob/master/test/tests.js#L7-L9
but that wouldn't be necessary without function name inference.
On Sat, Jan 28, 2017 at 8:11 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
> On Sat, Jan 28, 2017 at 3:46 PM, Allen Wirfs-Brock
> wrote:
> >
> >
> > > On Jan 27, 2017, at 7:26 AM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
> > >
> > > Two questions on the minor issue of the following not assigning a name
> > > to the function:
> > >
> > > ```js
> > > obj.foo = function() { };
> > > ```
> > >
> > > 1) Am I correct that the only reason it doesn't (in spec terms) is
> >
> >
> > No, the only reason it doesn’t is: by design, as directed by a decision
> made within a TC39 meeting.
>
> Yes, obviously. :-) By "in spec terms" I meant -- and thought in
> context was clear -- "in the language in the specification." I'm sorry
> if it wasn't clear.
>
> > > would mean it would assign the name `foo`?
> >
> > Yes, and for
> >cache[getUserSecret(user)] = function() {};
> > it would leak the secret user info as the value of name
>
> As does
>
> ```js
> cache = {
> [getUserSecret(user)]: function() {}
> };
> ```
>
> ...which while perhaps less likely for something called `cache` is, in
> the general case, just as much of a potential "leak". If secrecy is
> important, it's easily achieved:
>
> ```js
> cache[getUserSecret(user)] = function entry() {};
> ```
>
> > and for
> >obj[someSymbol] = function() {}
> > it would leak the Symbol value as the value of name
>
> It would *use* it as the name, yes, just like this does:
>
> ```js
> obj = {
> [someSymbol]: function() {}
> };
> ```
>
> Whether that's a *leak* depends on whether the code in question cares
> about that information being exposed. And again if that secrecy is
> important, it's trivially ensured (as above).
>
> > and for
> >table[n]=function() {}
> > name would likely be a numeric string
>
> Just as it does here:
>
> ```js
> obj = {
> [n]: function() {}
> };
> ```
>
> or here
>
> ```js
> obj = {
> 42: function() {}
> };
> ```
>
> I appreciate your taking the time to post those examples. I take it
> these are the objections you referred to in [July
> 2015](https://esdiscuss.org/topic/name-anonymous-functions-on-property-
> assignments#content-7)
> as why consensus couldn't be reached for this form?
>
> Thanks again,
>
> -- T.J.
> ___
> 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: name anonymous functions on property assignments
On Sat, Jan 28, 2017 at 3:46 PM, Allen Wirfs-Brock
wrote:
>
>
> > On Jan 27, 2017, at 7:26 AM, T.J. Crowder
> > wrote:
> >
> > Two questions on the minor issue of the following not assigning a name
> > to the function:
> >
> > ```js
> > obj.foo = function() { };
> > ```
> >
> > 1) Am I correct that the only reason it doesn't (in spec terms) is
>
>
> No, the only reason it doesn’t is: by design, as directed by a decision made
> within a TC39 meeting.
Yes, obviously. :-) By "in spec terms" I meant -- and thought in
context was clear -- "in the language in the specification." I'm sorry
if it wasn't clear.
> > would mean it would assign the name `foo`?
>
> Yes, and for
>cache[getUserSecret(user)] = function() {};
> it would leak the secret user info as the value of name
As does
```js
cache = {
[getUserSecret(user)]: function() {}
};
```
...which while perhaps less likely for something called `cache` is, in
the general case, just as much of a potential "leak". If secrecy is
important, it's easily achieved:
```js
cache[getUserSecret(user)] = function entry() {};
```
> and for
>obj[someSymbol] = function() {}
> it would leak the Symbol value as the value of name
It would *use* it as the name, yes, just like this does:
```js
obj = {
[someSymbol]: function() {}
};
```
Whether that's a *leak* depends on whether the code in question cares
about that information being exposed. And again if that secrecy is
important, it's trivially ensured (as above).
> and for
>table[n]=function() {}
> name would likely be a numeric string
Just as it does here:
```js
obj = {
[n]: function() {}
};
```
or here
```js
obj = {
42: function() {}
};
```
I appreciate your taking the time to post those examples. I take it
these are the objections you referred to in [July
2015](https://esdiscuss.org/topic/name-anonymous-functions-on-property-assignments#content-7)
as why consensus couldn't be reached for this form?
Thanks again,
-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: name anonymous functions on property assignments
> On Jan 27, 2017, at 7:26 AM, T.J. Crowder
> wrote:
>
> Two questions on the minor issue of the following not assigning a name
> to the function:
>
> ```js
> obj.foo = function() { };
> ```
>
> 1) Am I correct that the only reason it doesn't (in spec terms) is
No, the only reason it doesn’t is: by design, as directed by a decision made
within a TC39 meeting.
> that Step 1.e. of [Runtime Semantics:
> Evaluation](https://tc39.github.io/ecma262/#sec-assignment-operators-runtime-semantics-evaluation)
> reads
>
>> If IsAnonymousFunctionDefinition(AssignmentExpression) and IsIdentifierRef
>> of LeftHandSideExpression are both true, then
>
> and that changing that to
>
>> If IsAnonymousFunctionDefinition(AssignmentExpression) is true and either
>> IsIdentifierRef of LeftHandSideExpression is true or IsPropertyReference of
>> LeftHandSideExpression is true, then
>
> would mean it would assign the name `foo`?
Yes, and for
cache[getUserSecret(user)] = function() {};
it would leak the secret user info as the value of name
and for
obj[someSymbol] = function() {}
it would leak the Symbol value as the value of name
and for
table[n]=function() {}
name would likely be a numeric string
> (The subsequent step
> getting the name to use already uses GetReferencedName, which works
> for property references as well as identifier references.)
>
> 2) Are there any objections to closing this gap in how function names
> are assigned?
Yes there are!
In addition to the above, note that isIdentiferRef is a static semantic
operation. That means the the determination of whether a name will be attached
and the actual name can be determined statically prior to execution.
IsPropertyRef is a runtime operation and the new semantics require runtime
determination of the name value. This is all extra runtime work that may slow
down the creation of function closures that appear within loops.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: name anonymous functions on property assignments
Just for a bit of context, can you elaborate on how this broke your code?
Thanks
On 27 January 2017 at 16:56, Jordan Harband wrote:
> I'd have an objection. Function name inference has already broken my code
> - luckily only tests so far, that i know of - and doing it more often would
> break more of it.
>
> On Fri, Jan 27, 2017 at 7:26 AM, T.J. Crowder <
> tj.crow...@farsightsoftware.com> wrote:
>
>> Two questions on the minor issue of the following not assigning a name
>> to the function:
>>
>> ```js
>> obj.foo = function() { };
>> ```
>>
>> 1) Am I correct that the only reason it doesn't (in spec terms) is
>> that Step 1.e. of [Runtime Semantics:
>> Evaluation](https://tc39.github.io/ecma262/#sec-assignment-
>> operators-runtime-semantics-evaluation)
>> reads
>>
>> > If IsAnonymousFunctionDefinition(AssignmentExpression) and
>> IsIdentifierRef of LeftHandSideExpression are both true, then
>>
>> and that changing that to
>>
>> > If IsAnonymousFunctionDefinition(AssignmentExpression) is true and
>> either IsIdentifierRef of LeftHandSideExpression is true or
>> IsPropertyReference of LeftHandSideExpression is true, then
>>
>> would mean it would assign the name `foo`? (The subsequent step
>> getting the name to use already uses GetReferencedName, which works
>> for property references as well as identifier references.)
>>
>> 2) Are there any objections to closing this gap in how function names
>> are assigned?
>>
>> -- T.J.
>> ___
>> 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: SharedArrayBuffer: cloning vs transferring?
Thanks! This worked for me for a toy example (for multiple calls, I’d record
whether an exception was thrown during the first try):
```
try {
// Try new API (clone)
worker.postMessage({sharedBuffer});
} catch (e) {
// Fall back to old API (transfer)
worker.postMessage({sharedBuffer}, [sharedBuffer]);
}
```
Complete source code:
https://github.com/rauschma/shared-array-buffer-demo/blob/master/main.js
Axel
> On 25 Jan 2017, at 15:03, Lars Hansen wrote:
>
> You're asking about how postMessage() handles a SharedArrayBuffer, since the
> spec changed last summer from requiring the buffer to be in the transfer list
> to forbidding it. For the time being, Firefox allows the SAB to be in the
> transfer list but prints a warning in the console; by and by we will throw an
> error for that (and until then we'll fail any test cases that test for an
> exception). This is implemented in Firefox 51, if my testing right now is
> correct.
>
> Since no browser has officially shipped this functionality I think some
> browser sniffing may be reasonable for early adopters who want to operate in
> a multi-browser setting. I would expect that when this functionality is
> enabled by default in a browser the browser would adhere to the spec.
>
> --lars
>
>
> On Wed, Jan 25, 2017 at 10:49 AM, Axel Rauschmayer > wrote:
> AFAICT, all current implementations want you to transfer SABs. What’s the
> best way to prepare for the future? `try` transferring and clone in the
> `catch` clause?
>
> Thanks!
>
> Axel
>
> --
> Dr. Axel Rauschmayer
> rauschma.de
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
Dr. Axel Rauschmayer
a...@rauschma.de
dr-axel.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: name anonymous functions on property assignments
On Fri, Jan 27, 2017 at 4:56 PM, Jordan Harband wrote: > I'd have an objection. Function name inference has already broken my code - > luckily only tests so far, that i know of - and doing it more often would > break more of it. :-) Sorry to hear that. The ship has sailed on function name inference, though. It makes no sense to leave a gap in it like we have now. -- T.J. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
