Re: Template site objects and WeakMap
On Wed, Jun 17, 2015 at 11:19 AM, Yusuke SUZUKI utatane@gmail.com
wrote:
It turns out the spec is fine
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.set
step 5 says
If Type
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-data-types-and-values
(*key*) is not Object, throw a *TypeError* exception.
as I hoped and expected. The reason I was alarmed is that I got the
following behavior on v8/iojs:
var w = new WeakMap();
undefined
var r = Symbol.for('foo');
undefined
w.set(r, true);
{}
w.get(r)
true
I will file a v8 bug. Please someone, add a test for this to test262.
Ah, I see.
FYI (you may know deeper than I ;)), since symbols are primitive values,
they cannot be used as a WeakMap's key.
And since they are primitive values, they cannot have any properties. It
means that primitive values are immutable.
So Symbol.for / Symbol.keyFor's registry can be WeakMap in the internal
implementation.
Actually, we implemented so :D http://trac.webkit.org/changeset/182915
Yes, the important issue is the precondition in your since statement,
which v8 currently violates.
What do other browsers currently do?
By your observation at the start of this thread, we logically could have
specified that Symbols could be used as WeakMap keys as long as the WeakMap
held them strongly. Needless to say, I am glad we didn't ;).
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Template site objects and WeakMap
On 6/17/15 2:35 PM, Mark S. Miller wrote:
What do other browsers currently do?
Firefox:
var w = new WeakMap(); var r = Symbol.for('foo'); w.set(r, true);
TypeError: r is not a non-null object
WebKit nightly:
var w = new WeakMap(); var r = Symbol.for('foo'); w.set(r, true);
TypeError: Attempted to set a non-object key in a WeakMap
Don't have a new enough IE to test with offhand.
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Named `this` and `this` destructuring
On Wed, Jun 17, 2015 at 10:35 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
OK **that one** I've no idea what supposes to improve exactly ... I should
have tried to realize your proposal better, apologies.
After seeing that, I probably agree with Allen at this point we don't
really need that kind of syntax around JS (still IMHO, of course)
To each their own. :) I personally really like the bind syntax and have
received a tremendously positive feedback on it - the Trine project alone
has received over 1000 stars on GitHub, in under a week since release (last
Thursday), and it's just showcasing a part of the power of the proposed
syntax.
Best Regards
On Wed, Jun 17, 2015 at 6:01 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Wed, Jun 17, 2015 at 7:13 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 17, 2015, at 8:09 AM, Andrea Giammarchi wrote:
Mostly every Array extra in ES5 would work with those functions, e.g.
```js
function multiplyPoints (_p2) {
var { x1: x, y1: y } = this;
var { x2: x, y2: y } = _p2;
return { x: x1 * x2, y: y1 * y2 };
}
var multiplied = manyPoints.map(multiplyPoints, centralPoint);
```
It's not that common pattern but it gives you the ability to recycle
functions as both methods or filters or mappers or forEachers and
vice-versa.
I personally use those kind of functions quite a lot to be honest, most
developers keep ignoring Array extra second parameter as context though,
they probably use a wrapped fat arrow within an IFI with call(context) :D
It seems to me that we already can quite nicely express in ES6 the use
of a function as a method:
```js
function multiplyPoints({x1, y1}, {x2,y2}) {
return { x: x1 * x2, y: y1 * y2 }
}
class Point {
multiply(p2) {return multiplyPoints(this, p2)}
}
```
or, perhaps a bit more OO
```js
class Point {
static multiply({x1, y1}, {x2,y2}) {
return new Point(x1 * x2, y1 * y2 ) //or new this(...) if you
care about subclassing Point
}
multiply(p2) {return Point.multiply(this, p2)}
constructor(x,y) {
this.x = x;
this.x = y;
}
}
```
Regardless of how you express it, if you want the same function to be
used both as a standalone function and as an method, you are going to have
to have a line or two of code to install the function as a method. To me,
the one-line method definitions used above are about as concise and much
clearer in intent than `Point.prototype.multiply=multiplyPoints;` or
whatever other expression you would use to install such a function as a
method. And I would expect any high perf JIT to use inlining to completely
eliminate the indirection so, where it matters, there probably wound't be
any performance difference.
Many JS programmers have historically been confused about the JS
semantics of `this` because it is over-exposed in non-method functions.
Things like the current proposal increases rather than mitigates the
potential for such confusion. if you are programming in a functional style,
don't write functions that use `this`. If you need to transition from
to/from OO and functional styles, be explicit as shown above.
`this` is an OO concept. FP people, `this` is not for you; don't use
it, don't try to fix it.
But I already am [1][1], and it allows for a much nicer syntax than
functions that don't use `this`, and also composes well with built-ins
(other than Object.*) This proposal is building on the proposed function
bind syntax [2][2].
More examples of the power of the bind syntax can be found in the links,
but the bind syntax combined with my proposal would for example allow this:
```JS
function add (a, b) { return a + b; }
2::add(3) // 5
```
[1]: https://github.com/jussi-kalliokoski/trine
[2]: https://github.com/zenparsing/es-function-bind
Allen
___
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: Re: Template site objects and WeakMap
actually I was surprised the apparently mentioned native behavior looked
too much like my Symbol based WeakMap partial poly:
```js
var WeakMap = WeakMap || (function (s) {'use strict';
function WeakMap() {
this[s] = Symbol('WeakMap');
}
WeakMap.prototype = {
'delete': function del(o) {
delete o[this[s]];
},
get: function get(o) {
return o[this[s]];
},
has: function has(o) {
return -1 Object.getOwnPropertySymbols(o).indexOf(this[s]);
},
set: function set(o, v) {
o[this[s]] = v;
}
};
return WeakMap;
}(Symbol('WeakMap')));
```
weird to say the least, and yet I've no idea why that realm check would be
needed/done/reliable per each WeakMap.
Sorry for the noise, if any
On Wed, Jun 17, 2015 at 6:54 PM, Jordan Harband ljh...@gmail.com wrote:
Could I not use `Object(Symbol.for('some global registry symbol'))` as a
`WeakMap` key? That would return a realm-specific object, of course.
On Wed, Jun 17, 2015 at 10:19 AM, Benjamin Gruenbaum ing...@gmail.com
wrote:
congratulations and THANK YOU! I learned something important reading
your messages. The notion that we can preserve non-observability when
making one thing a WeakMap iff we make all other WeakMaps be strong for
those same objects is true, novel, and very surprising. I have been working
on such concepts for decades and never come across anything like it.
I apologize, I understand the problem with a weak registry forcing
observable garbage collection in user code - that's nice but isn't this
always the case with references to objects when an object pool/flyweight is
used?
Isn't this the same issue as `==` working on strings that have string
objects interned but possibly GC'd (and precisely why Java never collects
interned strings)?
___
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: Template site objects and WeakMap
It turns out the spec is fine
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.set
step 5 says
If Type
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-data-types-and-values
(*key*) is not Object, throw a *TypeError* exception.
as I hoped and expected. The reason I was alarmed is that I got the
following behavior on v8/iojs:
var w = new WeakMap();
undefined
var r = Symbol.for('foo');
undefined
w.set(r, true);
{}
w.get(r)
true
I will file a v8 bug. Please someone, add a test for this to test262.
Ah, I see.
FYI (you may know deeper than I ;)), since symbols are primitive values,
they cannot be used as a WeakMap's key.
And since they are primitive values, they cannot have any properties. It
means that primitive values are immutable.
So Symbol.for / Symbol.keyFor's registry can be WeakMap in the internal
implementation.
Actually, we implemented so :D http://trac.webkit.org/changeset/182915
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Template site objects and WeakMap
TypeError: Invalid value used as weak map key
Yes, already fixed on v8. Thanks.
On Wed, Jun 17, 2015 at 11:51 AM, Caitlin Potter caitpotte...@gmail.com
wrote:
The v8 bug referred to earlier in this thread was filed by Rick Waldron
and fixed back in March, I think engines are on the same page with this —
just FYI
On Jun 17, 2015, at 2:49 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/17/15 2:35 PM, Mark S. Miller wrote:
What do other browsers currently do?
Firefox:
var w = new WeakMap(); var r = Symbol.for('foo'); w.set(r, true);
TypeError: r is not a non-null object
WebKit nightly:
var w = new WeakMap(); var r = Symbol.for('foo'); w.set(r, true);
TypeError: Attempted to set a non-object key in a WeakMap
Don't have a new enough IE to test with offhand.
-Boris
___
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
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Template site objects and WeakMap
It would return a different object each time (for the same Symbol, like new
String) so it would not exhibit the problem of being observable.
On Jun 17, 2015, at 20:54, Jordan Harband ljh...@gmail.com wrote:
Could I not use `Object(Symbol.for('some global registry symbol'))` as a
`WeakMap` key? That would return a realm-specific object, of course.
On Wed, Jun 17, 2015 at 10:19 AM, Benjamin Gruenbaum ing...@gmail.com
wrote:
congratulations and THANK YOU! I learned something important reading your
messages. The notion that we can preserve non-observability when making
one thing a WeakMap iff we make all other WeakMaps be strong for those
same objects is true, novel, and very surprising. I have been working on
such concepts for decades and never come across anything like it.
I apologize, I understand the problem with a weak registry forcing
observable garbage collection in user code - that's nice but isn't this
always the case with references to objects when an object pool/flyweight is
used?
Isn't this the same issue as `==` working on strings that have string
objects interned but possibly GC'd (and precisely why Java never collects
interned strings)?
___
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: Template site objects and WeakMap
On Wed, Jun 17, 2015 at 9:31 AM, Yusuke SUZUKI utatane@gmail.com
wrote:
On Thu, Jun 18, 2015 at 1:18 AM, Mark S. Miller erig...@google.com
wrote:
[+Allen]
Can registered Symbols be used as keys in WeakMaps? If so, we have a
fatal unauthorized communications channel that we need to fix in the spec
asap!
Why do registered Symbols appear? (oops, maybe I missed some context...)
User exposed WeakMap only accepts objects as a key.
On Wed, Jun 17, 2015 at 10:00 AM, Benjamin Gruenbaum ing...@gmail.com
wrote:
Aren't WeakMap keys only objects?
It turns out the spec is fine
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.set
step 5 says
If Type
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-data-types-and-values
(*key*) is not Object, throw a *TypeError* exception.
as I hoped and expected. The reason I was alarmed is that I got the
following behavior on v8/iojs:
var w = new WeakMap();
undefined
var r = Symbol.for('foo');
undefined
w.set(r, true);
{}
w.get(r)
true
I will file a v8 bug. Please someone, add a test for this to test262.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Template site objects and WeakMap
The v8 bug referred to earlier in this thread was filed by Rick Waldron and
fixed back in March, I think engines are on the same page with this — just FYI
On Jun 17, 2015, at 2:49 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/17/15 2:35 PM, Mark S. Miller wrote:
What do other browsers currently do?
Firefox:
var w = new WeakMap(); var r = Symbol.for('foo'); w.set(r, true);
TypeError: r is not a non-null object
WebKit nightly:
var w = new WeakMap(); var r = Symbol.for('foo'); w.set(r, true);
TypeError: Attempted to set a non-object key in a WeakMap
Don't have a new enough IE to test with offhand.
-Boris
___
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: Named `this` and `this` destructuring
OK **that one** I've no idea what supposes to improve exactly ... I should
have tried to realize your proposal better, apologies.
After seeing that, I probably agree with Allen at this point we don't
really need that kind of syntax around JS (still IMHO, of course)
Best Regards
On Wed, Jun 17, 2015 at 6:01 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Wed, Jun 17, 2015 at 7:13 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 17, 2015, at 8:09 AM, Andrea Giammarchi wrote:
Mostly every Array extra in ES5 would work with those functions, e.g.
```js
function multiplyPoints (_p2) {
var { x1: x, y1: y } = this;
var { x2: x, y2: y } = _p2;
return { x: x1 * x2, y: y1 * y2 };
}
var multiplied = manyPoints.map(multiplyPoints, centralPoint);
```
It's not that common pattern but it gives you the ability to recycle
functions as both methods or filters or mappers or forEachers and
vice-versa.
I personally use those kind of functions quite a lot to be honest, most
developers keep ignoring Array extra second parameter as context though,
they probably use a wrapped fat arrow within an IFI with call(context) :D
It seems to me that we already can quite nicely express in ES6 the use
of a function as a method:
```js
function multiplyPoints({x1, y1}, {x2,y2}) {
return { x: x1 * x2, y: y1 * y2 }
}
class Point {
multiply(p2) {return multiplyPoints(this, p2)}
}
```
or, perhaps a bit more OO
```js
class Point {
static multiply({x1, y1}, {x2,y2}) {
return new Point(x1 * x2, y1 * y2 ) //or new this(...) if you care
about subclassing Point
}
multiply(p2) {return Point.multiply(this, p2)}
constructor(x,y) {
this.x = x;
this.x = y;
}
}
```
Regardless of how you express it, if you want the same function to be
used both as a standalone function and as an method, you are going to have
to have a line or two of code to install the function as a method. To me,
the one-line method definitions used above are about as concise and much
clearer in intent than `Point.prototype.multiply=multiplyPoints;` or
whatever other expression you would use to install such a function as a
method. And I would expect any high perf JIT to use inlining to completely
eliminate the indirection so, where it matters, there probably wound't be
any performance difference.
Many JS programmers have historically been confused about the JS
semantics of `this` because it is over-exposed in non-method functions.
Things like the current proposal increases rather than mitigates the
potential for such confusion. if you are programming in a functional style,
don't write functions that use `this`. If you need to transition from
to/from OO and functional styles, be explicit as shown above.
`this` is an OO concept. FP people, `this` is not for you; don't use
it, don't try to fix it.
But I already am [1][1], and it allows for a much nicer syntax than
functions that don't use `this`, and also composes well with built-ins
(other than Object.*) This proposal is building on the proposed function
bind syntax [2][2].
More examples of the power of the bind syntax can be found in the links,
but the bind syntax combined with my proposal would for example allow this:
```JS
function add (a, b) { return a + b; }
2::add(3) // 5
```
[1]: https://github.com/jussi-kalliokoski/trine
[2]: https://github.com/zenparsing/es-function-bind
Allen
___
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: Template site objects and WeakMap
uh ... never mind then, I don't even need to understand :D
Cheers
On Wed, Jun 17, 2015 at 7:51 PM, Caitlin Potter caitpotte...@gmail.com
wrote:
The v8 bug referred to earlier in this thread was filed by Rick Waldron
and fixed back in March, I think engines are on the same page with this —
just FYI
On Jun 17, 2015, at 2:49 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/17/15 2:35 PM, Mark S. Miller wrote:
What do other browsers currently do?
Firefox:
var w = new WeakMap(); var r = Symbol.for('foo'); w.set(r, true);
TypeError: r is not a non-null object
WebKit nightly:
var w = new WeakMap(); var r = Symbol.for('foo'); w.set(r, true);
TypeError: Attempted to set a non-object key in a WeakMap
Don't have a new enough IE to test with offhand.
-Boris
___
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: Re: Template site objects and WeakMap
Could I not use `Object(Symbol.for('some global registry symbol'))` as a
`WeakMap` key? That would return a realm-specific object, of course.
On Wed, Jun 17, 2015 at 10:19 AM, Benjamin Gruenbaum ing...@gmail.com
wrote:
congratulations and THANK YOU! I learned something important reading
your messages. The notion that we can preserve non-observability when
making one thing a WeakMap iff we make all other WeakMaps be strong for
those same objects is true, novel, and very surprising. I have been working
on such concepts for decades and never come across anything like it.
I apologize, I understand the problem with a weak registry forcing
observable garbage collection in user code - that's nice but isn't this
always the case with references to objects when an object pool/flyweight is
used?
Isn't this the same issue as `==` working on strings that have string
objects interned but possibly GC'd (and precisely why Java never collects
interned strings)?
___
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: Re: Template site objects and WeakMap
Interning of a particular immutable-objects-with-identity in an interning table can still safely be weakly interned, by marking that object, at interning time, so all WeakMaps from then on hold it strongly Oh cool, I didn't realize that. That is pretty neat :) On Wed, Jun 17, 2015 at 10:54 PM, Mark S. Miller erig...@google.com wrote: The idea that (a shared Weak interning table of immutable-objects-with-identity + WeakMaps makes gc observable) is not new. The idea that (the shared interning tables of immutable-objects-with-identity must therefore be strong) is not new. What was new to me is the idea that Interning of a particular immutable-objects-with-identity in an interning table can still safely be weakly interned, by marking that object, at interning time, so all WeakMaps from then on hold it strongly is new. At least to me. On Wed, Jun 17, 2015 at 10:19 AM, Benjamin Gruenbaum ing...@gmail.com wrote: congratulations and THANK YOU! I learned something important reading your messages. The notion that we can preserve non-observability when making one thing a WeakMap iff we make all other WeakMaps be strong for those same objects is true, novel, and very surprising. I have been working on such concepts for decades and never come across anything like it. I apologize, I understand the problem with a weak registry forcing observable garbage collection in user code - that's nice but isn't this always the case with references to objects when an object pool/flyweight is used? Isn't this the same issue as `==` working on strings that have string objects interned but possibly GC'd (and precisely why Java never collects interned strings)? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Template site objects and WeakMap
On 6/17/15 1:54 PM, Jordan Harband wrote:
Could I not use `Object(Symbol.for('some global registry symbol'))` as a
`WeakMap` key? That would return a realm-specific object, of course.
Object(Symbol.for(x)) == Object(Symbol.for(x)) tests false. That's
because http://www.ecma-international.org/ecma-262/6.0/#sec-object-value
reaches step 3 which lands you in
http://www.ecma-international.org/ecma-262/6.0/#sec-toobject which
returns a new Symbol object every time.
So while you _could_ use Object(Symbol.for('some global registry
symbol')) as a weakmap key it would not be terribly useful unless you
hung on to that object somewhere.
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Template site objects and WeakMap
The idea that (a shared Weak interning table of immutable-objects-with-identity + WeakMaps makes gc observable) is not new. The idea that (the shared interning tables of immutable-objects-with-identity must therefore be strong) is not new. What was new to me is the idea that Interning of a particular immutable-objects-with-identity in an interning table can still safely be weakly interned, by marking that object, at interning time, so all WeakMaps from then on hold it strongly is new. At least to me. On Wed, Jun 17, 2015 at 10:19 AM, Benjamin Gruenbaum ing...@gmail.com wrote: congratulations and THANK YOU! I learned something important reading your messages. The notion that we can preserve non-observability when making one thing a WeakMap iff we make all other WeakMaps be strong for those same objects is true, novel, and very surprising. I have been working on such concepts for decades and never come across anything like it. I apologize, I understand the problem with a weak registry forcing observable garbage collection in user code - that's nice but isn't this always the case with references to objects when an object pool/flyweight is used? Isn't this the same issue as `==` working on strings that have string objects interned but possibly GC'd (and precisely why Java never collects interned strings)? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript 2015 is now an Ecma Standard
On 15-06-17 12:46 PM, Allen Wirfs-Brock wrote: Ecma international has announced that its General Assembly has approved ECMA-262-6 /The ECMAScript 2015 Language Specification/ as an Ecma standard http://www.ecma-international.org/news/index.html Congrats! The official document is now available from Ecma in HTML at http://www.ecma-international.org/ecma-262/6.0 and as a PDF at http://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf So is this effectively rev39 (referred to in bug responses)? Where should bug reports on 6th edition go? (bugs.ecmascript.org doesn't appear to have an appropriate product category.) -Michael ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Template site objects and WeakMap
this is puzzling me too ... so I've got few cases 1. you want/need a one to many relations, Symbol as key, Array as value, and you play with that Array values as needed per each Symbol used as key in the very same WeakMap 2. you invert the logic and you have a WeakMap that checks per each object of the value Symbol has been set already 3. you want to use that very same Symbol with that object, but that objet is not extensible, so you fallback through a private WeakMap that associates such object instead of using Symbol directly which case was that? Cheers On Wed, Jun 17, 2015 at 10:08 PM, Mark S. Miller erig...@google.com wrote: I am curious about what these are? But regardless, I would expect there to be examples where it would be useful if it weren't fatal. Regarding the issues in this thread, it actually would be safe to allow unregistered Symbols as keys. But unless these examples are tremendously compelling, please let's not. On Wed, Jun 17, 2015 at 1:51 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 17, 2015, at 9:18 AM, Mark S. Miller wrote: [+Allen] Can registered Symbols be used as keys in WeakMaps? If so, we have a fatal unauthorized communications channel that we need to fix in the spec asap! No, symbols are not objects and the keys of WeakMaps must be objects. BTW, some people have identified use cases where allowing symbols values as WeakMap keys would be useful. Allen -- Cheers, --MarkM ___ 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: ECMAScript 2015 is now an Ecma Standard
Congrats the whole TC-39, and special thanks to Allen Wirfs-Brock for the actual great editorial work on the spec! Dmitry On Wed, Jun 17, 2015 at 9:46 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Ecma international has announced that its General Assembly has approved ECMA-262-6 *The ECMAScript 2015 Language Specification* as an Ecma standard http://www.ecma-international.org/news/index.html The official document is now available from Ecma in HTML at http://www.ecma-international.org/ecma-262/6.0 and as a PDF at http://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf I recommend that people immediately start using the Ecma HTML version in discussion where they need to link references to sections of the specification. Allen ___ 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: Named `this` and `this` destructuring
On Jun 17, 2015, at 10:01 AM, Jussi Kalliokoski wrote:
...
More examples of the power of the bind syntax can be found in the links, but
the bind syntax combined with my proposal would for example allow this:
```JS
function add (a, b) { return a + b; }
2::add(3) // 5
```
and why that better than:
```js
function add(a,b) {return a+b}
add(2,3);
```
Every new feature increases the conceptual complexity of a language and to
justify that it needs to provide a big pay back. This doesn't seem to have
much of a pay back. Adding the and :: doesn't eliminate the need for JS
programmer to learn about `this` in functions for the various already existing
ways to call a function with an explicit `this` value. It just add more new
syntax that needs to be learned and remembered are move feature interactions
that have to be understood.
JS doesn't need more syntax and semantics piled on to `this`. Ideally some
would be taken away. However, the latter is not possible.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript 2015 is now an Ecma Standard
On Jun 17, 2015, at 2:34 PM, Michael Dyck wrote: On 15-06-17 12:46 PM, Allen Wirfs-Brock wrote: Ecma international has announced that its General Assembly has approved ECMA-262-6 /The ECMAScript 2015 Language Specification/ as an Ecma standard http://www.ecma-international.org/news/index.html Congrats! The official document is now available from Ecma in HTML at http://www.ecma-international.org/ecma-262/6.0 and as a PDF at http://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf So is this effectively rev39 (referred to in bug responses)? yes, I'll be posting a change summary for rev39 Where should bug reports on 6th edition go? (bugs.ecmascript.org doesn't appear to have an appropriate product category.) I've now reated a product for the 6th Edition. The Draft for 6th Edition product is now closed for new bug submissions. https://bugs.ecmascript.org/describecomponents.cgi Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Named `this` and `this` destructuring
the ::bind syntax is OK (I don't really like that double colon 'cause it's
not semantic at all with the single colon meaning but I can live with it)
but having potential bitwise-like operators around to adress a possible
context ... well, I wouldn't probably use/need that in the short, or even
long, term.
Again, just my opinion, listen to others ;-)
On Wed, Jun 17, 2015 at 8:40 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Wed, Jun 17, 2015 at 10:35 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
OK **that one** I've no idea what supposes to improve exactly ... I
should have tried to realize your proposal better, apologies.
After seeing that, I probably agree with Allen at this point we don't
really need that kind of syntax around JS (still IMHO, of course)
To each their own. :) I personally really like the bind syntax and have
received a tremendously positive feedback on it - the Trine project alone
has received over 1000 stars on GitHub, in under a week since release (last
Thursday), and it's just showcasing a part of the power of the proposed
syntax.
Best Regards
On Wed, Jun 17, 2015 at 6:01 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Wed, Jun 17, 2015 at 7:13 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jun 17, 2015, at 8:09 AM, Andrea Giammarchi wrote:
Mostly every Array extra in ES5 would work with those functions, e.g.
```js
function multiplyPoints (_p2) {
var { x1: x, y1: y } = this;
var { x2: x, y2: y } = _p2;
return { x: x1 * x2, y: y1 * y2 };
}
var multiplied = manyPoints.map(multiplyPoints, centralPoint);
```
It's not that common pattern but it gives you the ability to recycle
functions as both methods or filters or mappers or forEachers and
vice-versa.
I personally use those kind of functions quite a lot to be honest, most
developers keep ignoring Array extra second parameter as context though,
they probably use a wrapped fat arrow within an IFI with call(context) :D
It seems to me that we already can quite nicely express in ES6 the use
of a function as a method:
```js
function multiplyPoints({x1, y1}, {x2,y2}) {
return { x: x1 * x2, y: y1 * y2 }
}
class Point {
multiply(p2) {return multiplyPoints(this, p2)}
}
```
or, perhaps a bit more OO
```js
class Point {
static multiply({x1, y1}, {x2,y2}) {
return new Point(x1 * x2, y1 * y2 ) //or new this(...) if you
care about subclassing Point
}
multiply(p2) {return Point.multiply(this, p2)}
constructor(x,y) {
this.x = x;
this.x = y;
}
}
```
Regardless of how you express it, if you want the same function to be
used both as a standalone function and as an method, you are going to have
to have a line or two of code to install the function as a method. To me,
the one-line method definitions used above are about as concise and much
clearer in intent than `Point.prototype.multiply=multiplyPoints;` or
whatever other expression you would use to install such a function as a
method. And I would expect any high perf JIT to use inlining to completely
eliminate the indirection so, where it matters, there probably wound't be
any performance difference.
Many JS programmers have historically been confused about the JS
semantics of `this` because it is over-exposed in non-method functions.
Things like the current proposal increases rather than mitigates the
potential for such confusion. if you are programming in a functional style,
don't write functions that use `this`. If you need to transition from
to/from OO and functional styles, be explicit as shown above.
`this` is an OO concept. FP people, `this` is not for you; don't use
it, don't try to fix it.
But I already am [1][1], and it allows for a much nicer syntax than
functions that don't use `this`, and also composes well with built-ins
(other than Object.*) This proposal is building on the proposed function
bind syntax [2][2].
More examples of the power of the bind syntax can be found in the links,
but the bind syntax combined with my proposal would for example allow this:
```JS
function add (a, b) { return a + b; }
2::add(3) // 5
```
[1]: https://github.com/jussi-kalliokoski/trine
[2]: https://github.com/zenparsing/es-function-bind
Allen
___
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: ECMAScript 2015 is now an Ecma Standard
The official document is now available from Ecma in HTML at http://www.ecma-international.org/ecma-262/6.0 http://www.ecma-international.org/ecma-262/6.0 and as a PDF at http://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf http://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf I recommend that people immediately start using the Ecma HTML version in discussion where they need to link references to sections of the specification. FWIW: I’ve made a list of all IDs from the old ES6 HTML spec [1] that don’t work anymore (spoiler: only a few of the symbolic ones): https://gist.github.com/rauschma/c144d5d58d7afb3d88b8 [1] https://people.mozilla.org/~jorendorff/es6-draft.html -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Template site objects and WeakMap
On Jun 17, 2015, at 9:18 AM, Mark S. Miller wrote: [+Allen] Can registered Symbols be used as keys in WeakMaps? If so, we have a fatal unauthorized communications channel that we need to fix in the spec asap! No, symbols are not objects and the keys of WeakMaps must be objects. BTW, some people have identified use cases where allowing symbols values as WeakMap keys would be useful. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Named `this` and `this` destructuring
On Wed, Jun 17, 2015 at 10:45 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
the ::bind syntax is OK (I don't really like that double colon 'cause it's
not semantic at all with the single colon meaning but I can live with it)
but having potential bitwise-like operators around to adress a possible
context ... well, I wouldn't probably use/need that in the short, or even
long, term.
Again, just my opinion, listen to others ;-)
Ah sorry, my bad, I misunderstood you. :) To clarify, I've only heard
positive feedback from people of the bind syntax; as for this proposal,
this thread is the first time I hear feedback and it doesn't seem overtly
positive. :P
On Wed, Jun 17, 2015 at 8:40 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Wed, Jun 17, 2015 at 10:35 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
OK **that one** I've no idea what supposes to improve exactly ... I
should have tried to realize your proposal better, apologies.
After seeing that, I probably agree with Allen at this point we don't
really need that kind of syntax around JS (still IMHO, of course)
To each their own. :) I personally really like the bind syntax and have
received a tremendously positive feedback on it - the Trine project alone
has received over 1000 stars on GitHub, in under a week since release (last
Thursday), and it's just showcasing a part of the power of the proposed
syntax.
Best Regards
On Wed, Jun 17, 2015 at 6:01 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Wed, Jun 17, 2015 at 7:13 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jun 17, 2015, at 8:09 AM, Andrea Giammarchi wrote:
Mostly every Array extra in ES5 would work with those functions, e.g.
```js
function multiplyPoints (_p2) {
var { x1: x, y1: y } = this;
var { x2: x, y2: y } = _p2;
return { x: x1 * x2, y: y1 * y2 };
}
var multiplied = manyPoints.map(multiplyPoints, centralPoint);
```
It's not that common pattern but it gives you the ability to recycle
functions as both methods or filters or mappers or forEachers and
vice-versa.
I personally use those kind of functions quite a lot to be honest,
most developers keep ignoring Array extra second parameter as context
though, they probably use a wrapped fat arrow within an IFI with
call(context) :D
It seems to me that we already can quite nicely express in ES6 the
use of a function as a method:
```js
function multiplyPoints({x1, y1}, {x2,y2}) {
return { x: x1 * x2, y: y1 * y2 }
}
class Point {
multiply(p2) {return multiplyPoints(this, p2)}
}
```
or, perhaps a bit more OO
```js
class Point {
static multiply({x1, y1}, {x2,y2}) {
return new Point(x1 * x2, y1 * y2 ) //or new this(...) if you
care about subclassing Point
}
multiply(p2) {return Point.multiply(this, p2)}
constructor(x,y) {
this.x = x;
this.x = y;
}
}
```
Regardless of how you express it, if you want the same function to be
used both as a standalone function and as an method, you are going to have
to have a line or two of code to install the function as a method. To me,
the one-line method definitions used above are about as concise and much
clearer in intent than `Point.prototype.multiply=multiplyPoints;` or
whatever other expression you would use to install such a function as a
method. And I would expect any high perf JIT to use inlining to
completely
eliminate the indirection so, where it matters, there probably wound't be
any performance difference.
Many JS programmers have historically been confused about the JS
semantics of `this` because it is over-exposed in non-method functions.
Things like the current proposal increases rather than mitigates the
potential for such confusion. if you are programming in a functional
style,
don't write functions that use `this`. If you need to transition from
to/from OO and functional styles, be explicit as shown above.
`this` is an OO concept. FP people, `this` is not for you; don't use
it, don't try to fix it.
But I already am [1][1], and it allows for a much nicer syntax than
functions that don't use `this`, and also composes well with built-ins
(other than Object.*) This proposal is building on the proposed function
bind syntax [2][2].
More examples of the power of the bind syntax can be found in the
links, but the bind syntax combined with my proposal would for example
allow this:
```JS
function add (a, b) { return a + b; }
2::add(3) // 5
```
[1]: https://github.com/jussi-kalliokoski/trine
[2]: https://github.com/zenparsing/es-function-bind
Allen
___
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
revive let blocks
I'd like to ask if there's anyone on TC39 that would be willing to champion a
proposal to add the let-block (let-statement) syntax?
I currently write my block-scoped declarations as:
```js
{ let a = 2, b, c;
// ..
}
```
I do this because I want to be in the habit of always putting my `let`
declarations at the top of blocks to avoid TDZ hazards. However, Firefox has
long had the alternate let-block/statement syntax, which I prefer:
```js
let (a = 2, b, c) {
// ..
}
```
Would there be support to consider such a proposal?
Side note: I'd also be in favor of a `const (a = 2) { .. }` form, if the
symmetry was appealing.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript 2015 is now an Ecma Standard
Filed Pull Requests to es6-shim and core-js to match the late change to the `Promise.reject` text. Yay final spec! --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Template site objects and WeakMap
congratulations and THANK YOU! I learned something important reading your messages. The notion that we can preserve non-observability when making one thing a WeakMap iff we make all other WeakMaps be strong for those same objects is true, novel, and very surprising. I have been working on such concepts for decades and never come across anything like it. I apologize, I understand the problem with a weak registry forcing observable garbage collection in user code - that's nice but isn't this always the case with references to objects when an object pool/flyweight is used? Isn't this the same issue as `==` working on strings that have string objects interned but possibly GC'd (and precisely why Java never collects interned strings)? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Template site objects and WeakMap
I am curious about what these are? But regardless, I would expect there to be examples where it would be useful if it weren't fatal. Regarding the issues in this thread, it actually would be safe to allow unregistered Symbols as keys. But unless these examples are tremendously compelling, please let's not. On Wed, Jun 17, 2015 at 1:51 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 17, 2015, at 9:18 AM, Mark S. Miller wrote: [+Allen] Can registered Symbols be used as keys in WeakMaps? If so, we have a fatal unauthorized communications channel that we need to fix in the spec asap! No, symbols are not objects and the keys of WeakMaps must be objects. BTW, some people have identified use cases where allowing symbols values as WeakMap keys would be useful. Allen -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Named `this` and `this` destructuring
Exactly what Allen said. Adding syntax to work around a bad feature is an awful idea. We should be trying to reduce and remove usage of `this` by reducing resistance to other ways of programming in JavaScript. Minimal API Surface areas apply to languages, not just libraries. http://2014.jsconf.eu/speakers/sebastian-markbage-minimal-api-surface-area-learning-patterns-instead-of-frameworks.html http://2014.jsconf.eu/speakers/sebastian-markbage-minimal-api-surface-area-learning-patterns-instead-of-frameworks.html___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Named `this` and `this` destructuring
It's probably a bit early for this, but I figured I'd put it out there (I
already proposed this as a tangent in the function bind syntax thread).
This syntax proposal is purely about convenience and subjective
expressiveness (like any feature addition to a Turing complete language).
As I've been building Trine, I noticed that the `this` as data pattern is
extremely powerful and expressive, however the code in the functions
doesn't convey the intent very clearly. For example:
function add (b) { return this + b; }
function * map (fn) { for ( let item of this ) { yield item::fn(); } }
vs.
function add (a, b) { return a + b; }
function * map (iterator, fn) { for ( let item of iterator ) { yield
item::fn(); } }
Also currently neither Flow or TypeScript support type annotating this.
There's discussion [1] [2] in both the projects for allowing `this` to be
specified as a parameter to allow annotating it, e.g.
function add (this : number, b : number) : number { return this + b; }
This leads to my current proposal, i.e. being able to make the first
parameter of the function an alias for `this` by using a special prefix
(). This would not only allow aliasing `this`, but also destructuring and
default values (as well as type annotation in language extensions).
The different forms and their desugarings:
function add (a, b) {
return a + b;
}
// would desugar to
function add (b) {
var a = this;
return a + b;
}
function multiplyTuple ([a, b], multiplier) {
return [a * multiplier, b * multiplier];
}
// would desugar to
function multiplyTuple (multiplier) {
var [a, b] = this;
return [a * multiplier, b * multiplier];
}
function multiplyPoints ({ x1: x, y1: y }, { x2: x, y2: y }) {
return { x: x1 * x2, y: y1 * y2 };
}
// would desugar to
function multiplyPoints (_p2) {
var { x1: x, y1: y } = this;
var { x2: x, y2: y } = _p2;
return { x: x1 * x2, y: y1 * y2 };
}
// allow passing the element for mocking in tests
function isQsaSupported (dummyElement = document) {
return typeof dummyElement.querySelectorAll !== undefined;
}
This proposal would also be consistent with the type annotation proposals
for `this` mentioned earlier.
WDYT?
[1] https://github.com/facebook/flow/issues/452
[2] https://github.com/Microsoft/TypeScript/issues/1985
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Template site objects and WeakMap
Hi Yusuke, congratulations and THANK YOU! I learned something important
reading your messages. The notion that we can preserve non-observability
when making one thing a WeakMap iff we make all other WeakMaps be strong
for those same objects is true, novel, and very surprising. I have been
working on such concepts for decades and never come across anything like it.
In this case, I suspect that implementers will continue to choose the
memory leak rather than make WeakMap more complex in this way. But you have
now given them a choice, which is great! The spec does not need to change
to enable this choice. The spec is only about observable differences, and
the space optimization you suggest would be unobservable.
Your observation, being general, may find other applications even if it is
not used to optimize this one. This observation is not language specific;
it may well find application in other memory safe languages including those
yet to be invented. You have added another tool to our toolbox. You have
deepened our understanding of what is possible.
On Tue, Jun 16, 2015 at 10:45 PM, Yusuke SUZUKI utatane@gmail.com
wrote:
On Wed, Jun 17, 2015 at 2:29 PM, Yusuke SUZUKI utatane@gmail.com
wrote:
Thanks. And sorry for the late reply.
On Wed, Jun 17, 2015 at 11:31 AM, Mark S. Miller erig...@google.com
wrote:
Hi Yusuke, I am not sure I understood your message. Could you show some
example code that would observe the observable difference you have in mind?
On Tue, Jun 16, 2015 at 7:25 PM, Yusuke SUZUKI utatane@gmail.com
wrote:
Hi forks,
In ES6 spec, template site objects are strongly referenced by the
realm.[[templateMap]].
So naive implementation leaks memory because it keeps all the site
objects in the realm.
To lookup the identical template site objects, template site objects are
stored in the realm.[[templateMap]].
So they are strongly referenced and the naive implementation leaks memory.
// By writing the following code, we can leak memory that GC cannot
collect.
function tag(siteObject)
{
return siteObject;
}
for (var i = 0;; ++i) {
eval(tag` + i + `);
}
However, we can alleviate this situation.
Because template site objects are frozen completely, it behaves as if
it's a primitive value.
It enables the implementation to reference it from the realm weakly.
When all disclosed site objects are not referenced, we can GC them because
nobody knows the given site object is once collected ( re-generated).
By implementing the realm.[[templateMap]] as WeakMap, we can alleviate
this situation.
function tag(siteObject) {
// Since siteObject is frozen, we cannot attach a property to it.
// So if nobody has the reference to the siteObject, we can collect
this siteObject since identity can not be tested across already collected
newly created site object.
}
But, even if the object is frozen, we can bind the property with it
indirectly by using WeakMap.
As a result, if the site objects are referenced by the realm weakly,
users can observe it by using WeakMap.
var map = new WeakMap();
function tag(siteObject) {
return siteObject;
}
var siteObject = tag`hello`;
map.set(siteObject, true);
gc(); // If realm.[[templateMap]] is implemente by the WeakMap,
siteObject will be collected.
var siteObject = tag`hello`;
map.get(siteObject); // false, but should be true.
To avoid this situation, we need to specially handle template site
objects in WeakMap; WeakMap refers template site objects strongly (if we
choose the weak reference implementation for realm.[[templateMap]]).
But this may complicate the implementation and it may prevent
implementing WeakMap as per-object table (it can be done, but it is no
longer simple private symbols).
var map = new WeakMap();
function tag(siteObject) {
return siteObject;
}
tag`hello`;
gc(); // siteObject can be collected because there's no reference to it
if the [[templateMap]] is implemented as WeakMap.
var siteObject = tag`hello`;
map.set(siteObject, true); // To avoid the previously described
situation, WeakMap specially handles the siteObject. It is now refereneced
strongly by the WeakMap.
gc();
var siteObject = tag`hello`;
map.get(siteObject); // true
// And if WeakMap is collected, siteObject can be collected.
Fix.
var map = new WeakMap();
function tag(siteObject) {
return siteObject;
}
tag`hello`;
gc(); // siteObject can be collected because there's no reference to it
if the [[templateMap]] is implemented as WeakMap.
(function () {
var siteObject = tag`hello`;
map.set(siteObject, true); // To avoid the previously described
situation, WeakMap specially handles the siteObject. It is now refereneced
strongly by the WeakMap.
}());
gc();
(function () {
var siteObject = tag`hello`;
map.get(siteObject); // true
}());
// And if WeakMap is collected, siteObject can be collected.
map = null;
Re: Named `this` and `this` destructuring
Mostly every Array extra in ES5 would work with those functions, e.g.
```js
function multiplyPoints (_p2) {
var { x1: x, y1: y } = this;
var { x2: x, y2: y } = _p2;
return { x: x1 * x2, y: y1 * y2 };
}
var multiplied = manyPoints.map(multiplyPoints, centralPoint);
```
It's not that common pattern but it gives you the ability to recycle
functions as both methods or filters or mappers or forEachers and
vice-versa.
I personally use those kind of functions quite a lot to be honest, most
developers keep ignoring Array extra second parameter as context though,
they probably use a wrapped fat arrow within an IFI with call(context) :D
Best Regards
On Wed, Jun 17, 2015 at 3:53 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
Could you include some examples of *calling* functions defined this way?
The most obvious way uses `Function#call` and would be terribly awkward.
Perhaps I'm just overlooking some ES6 feature which makes passing a
specific `this` value easy?
It seems curious that you are not using methods instead of functions.
--scott
On Wed, Jun 17, 2015 at 2:41 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
It's probably a bit early for this, but I figured I'd put it out there (I
already proposed this as a tangent in the function bind syntax thread).
This syntax proposal is purely about convenience and subjective
expressiveness (like any feature addition to a Turing complete language).
As I've been building Trine, I noticed that the `this` as data pattern
is extremely powerful and expressive, however the code in the functions
doesn't convey the intent very clearly. For example:
function add (b) { return this + b; }
function * map (fn) { for ( let item of this ) { yield item::fn(); } }
vs.
function add (a, b) { return a + b; }
function * map (iterator, fn) { for ( let item of iterator ) { yield
item::fn(); } }
Also currently neither Flow or TypeScript support type annotating this.
There's discussion [1] [2] in both the projects for allowing `this` to be
specified as a parameter to allow annotating it, e.g.
function add (this : number, b : number) : number { return this + b; }
This leads to my current proposal, i.e. being able to make the first
parameter of the function an alias for `this` by using a special prefix
(). This would not only allow aliasing `this`, but also destructuring and
default values (as well as type annotation in language extensions).
The different forms and their desugarings:
function add (a, b) {
return a + b;
}
// would desugar to
function add (b) {
var a = this;
return a + b;
}
function multiplyTuple ([a, b], multiplier) {
return [a * multiplier, b * multiplier];
}
// would desugar to
function multiplyTuple (multiplier) {
var [a, b] = this;
return [a * multiplier, b * multiplier];
}
function multiplyPoints ({ x1: x, y1: y }, { x2: x, y2: y }) {
return { x: x1 * x2, y: y1 * y2 };
}
// would desugar to
function multiplyPoints (_p2) {
var { x1: x, y1: y } = this;
var { x2: x, y2: y } = _p2;
return { x: x1 * x2, y: y1 * y2 };
}
// allow passing the element for mocking in tests
function isQsaSupported (dummyElement = document) {
return typeof dummyElement.querySelectorAll !== undefined;
}
This proposal would also be consistent with the type annotation proposals
for `this` mentioned earlier.
WDYT?
[1] https://github.com/facebook/flow/issues/452
[2] https://github.com/Microsoft/TypeScript/issues/1985
___
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: Named `this` and `this` destructuring
Could you include some examples of *calling* functions defined this way?
The most obvious way uses `Function#call` and would be terribly awkward.
Perhaps I'm just overlooking some ES6 feature which makes passing a
specific `this` value easy?
It seems curious that you are not using methods instead of functions.
--scott
On Wed, Jun 17, 2015 at 2:41 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
It's probably a bit early for this, but I figured I'd put it out there (I
already proposed this as a tangent in the function bind syntax thread).
This syntax proposal is purely about convenience and subjective
expressiveness (like any feature addition to a Turing complete language).
As I've been building Trine, I noticed that the `this` as data pattern
is extremely powerful and expressive, however the code in the functions
doesn't convey the intent very clearly. For example:
function add (b) { return this + b; }
function * map (fn) { for ( let item of this ) { yield item::fn(); } }
vs.
function add (a, b) { return a + b; }
function * map (iterator, fn) { for ( let item of iterator ) { yield
item::fn(); } }
Also currently neither Flow or TypeScript support type annotating this.
There's discussion [1] [2] in both the projects for allowing `this` to be
specified as a parameter to allow annotating it, e.g.
function add (this : number, b : number) : number { return this + b; }
This leads to my current proposal, i.e. being able to make the first
parameter of the function an alias for `this` by using a special prefix
(). This would not only allow aliasing `this`, but also destructuring and
default values (as well as type annotation in language extensions).
The different forms and their desugarings:
function add (a, b) {
return a + b;
}
// would desugar to
function add (b) {
var a = this;
return a + b;
}
function multiplyTuple ([a, b], multiplier) {
return [a * multiplier, b * multiplier];
}
// would desugar to
function multiplyTuple (multiplier) {
var [a, b] = this;
return [a * multiplier, b * multiplier];
}
function multiplyPoints ({ x1: x, y1: y }, { x2: x, y2: y }) {
return { x: x1 * x2, y: y1 * y2 };
}
// would desugar to
function multiplyPoints (_p2) {
var { x1: x, y1: y } = this;
var { x2: x, y2: y } = _p2;
return { x: x1 * x2, y: y1 * y2 };
}
// allow passing the element for mocking in tests
function isQsaSupported (dummyElement = document) {
return typeof dummyElement.querySelectorAll !== undefined;
}
This proposal would also be consistent with the type annotation proposals
for `this` mentioned earlier.
WDYT?
[1] https://github.com/facebook/flow/issues/452
[2] https://github.com/Microsoft/TypeScript/issues/1985
___
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
ECMAScript 2015 is now an Ecma Standard
Ecma international has announced that its General Assembly has approved ECMA-262-6 The ECMAScript 2015 Language Specification as an Ecma standard http://www.ecma-international.org/news/index.html The official document is now available from Ecma in HTML at http://www.ecma-international.org/ecma-262/6.0 and as a PDF at http://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf I recommend that people immediately start using the Ecma HTML version in discussion where they need to link references to sections of the specification. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript 2015 is now an Ecma Standard
congratulations and I recommend that people immediately start using the Ecma HTML version in discussion where they need to link references to sections of the specification. good advice ! Best Regards On Wed, Jun 17, 2015 at 5:46 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Ecma international has announced that its General Assembly has approved ECMA-262-6 *The ECMAScript 2015 Language Specification* as an Ecma standard http://www.ecma-international.org/news/index.html The official document is now available from Ecma in HTML at http://www.ecma-international.org/ecma-262/6.0 and as a PDF at http://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf I recommend that people immediately start using the Ecma HTML version in discussion where they need to link references to sections of the specification. Allen ___ 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: ECMAScript 2015 is now an Ecma Standard
This is awesome news - now to get someone to make something similar to es5.github.io in terms of readability and ease of use :) On Jun 17, 2015, at 19:46, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Ecma international has announced that its General Assembly has approved ECMA-262-6 The ECMAScript 2015 Language Specification as an Ecma standard http://www.ecma-international.org/news/index.html The official document is now available from Ecma in HTML at http://www.ecma-international.org/ecma-262/6.0 and as a PDF at http://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf I recommend that people immediately start using the Ecma HTML version in discussion where they need to link references to sections of the specification. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Template site objects and WeakMap
Aren't WeakMap keys only objects? On Jun 17, 2015, at 19:18, Mark S. Miller erig...@google.com wrote: [+Allen] Can registered Symbols be used as keys in WeakMaps? If so, we have a fatal unauthorized communications channel that we need to fix in the spec asap! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript 2015 is now an Ecma Standard
Lots of the changes were long awaited. ES2015 is an important milestone. More important even is the momentum and recent changes to the way people can contribute to the standard. Thank you to everyone involved in making all of this happen! David Le 17/06/2015 17:46, Allen Wirfs-Brock a écrit : Ecma international has announced that its General Assembly has approved ECMA-262-6 /The ECMAScript 2015 Language Specification/ as an Ecma standard http://www.ecma-international.org/news/index.html The official document is now available from Ecma in HTML at http://www.ecma-international.org/ecma-262/6.0 and as a PDF at http://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf I recommend that people immediately start using the Ecma HTML version in discussion where they need to link references to sections of the specification. Allen ___ 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: Named `this` and `this` destructuring
I forgot to mention that those functions I use as both methods and
map/filters are most of the time **private** , and yet we haven't
introduced private methods within current class specification.
Functions with a `this` are very portable/handy within closures, combined
with Array extras and .call/.apply to use them as private methods has been
very well known and used pattern since ES3
I'm not saying this proposal improve much in current ES6 specification, I'm
saying there are very valid use cases for having a `this` in a non method
function.
Regards
On Wed, Jun 17, 2015 at 5:13 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jun 17, 2015, at 8:09 AM, Andrea Giammarchi wrote:
Mostly every Array extra in ES5 would work with those functions, e.g.
```js
function multiplyPoints (_p2) {
var { x1: x, y1: y } = this;
var { x2: x, y2: y } = _p2;
return { x: x1 * x2, y: y1 * y2 };
}
var multiplied = manyPoints.map(multiplyPoints, centralPoint);
```
It's not that common pattern but it gives you the ability to recycle
functions as both methods or filters or mappers or forEachers and
vice-versa.
I personally use those kind of functions quite a lot to be honest, most
developers keep ignoring Array extra second parameter as context though,
they probably use a wrapped fat arrow within an IFI with call(context) :D
It seems to me that we already can quite nicely express in ES6 the use of
a function as a method:
```js
function multiplyPoints({x1, y1}, {x2,y2}) {
return { x: x1 * x2, y: y1 * y2 }
}
class Point {
multiply(p2) {return multiplyPoints(this, p2)}
}
```
or, perhaps a bit more OO
```js
class Point {
static multiply({x1, y1}, {x2,y2}) {
return new Point(x1 * x2, y1 * y2 ) //or new this(...) if you care
about subclassing Point
}
multiply(p2) {return Point.multiply(this, p2)}
constructor(x,y) {
this.x = x;
this.x = y;
}
}
```
Regardless of how you express it, if you want the same function to be used
both as a standalone function and as an method, you are going to have to
have a line or two of code to install the function as a method. To me, the
one-line method definitions used above are about as concise and much
clearer in intent than `Point.prototype.multiply=multiplyPoints;` or
whatever other expression you would use to install such a function as a
method. And I would expect any high perf JIT to use inlining to completely
eliminate the indirection so, where it matters, there probably wound't be
any performance difference.
Many JS programmers have historically been confused about the JS semantics
of `this` because it is over-exposed in non-method functions. Things like
the current proposal increases rather than mitigates the potential for such
confusion. if you are programming in a functional style, don't write
functions that use `this`. If you need to transition from to/from OO and
functional styles, be explicit as shown above.
`this` is an OO concept. FP people, `this` is not for you; don't use it,
don't try to fix it.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Template site objects and WeakMap
On Thu, Jun 18, 2015 at 1:18 AM, Mark S. Miller erig...@google.com wrote: [+Allen] Can registered Symbols be used as keys in WeakMaps? If so, we have a fatal unauthorized communications channel that we need to fix in the spec asap! Why do registered Symbols appear? (oops, maybe I missed some context...) User exposed WeakMap only accepts objects as a key. In an inverted per-object table implementation, I've talked in this context[1, 2] Now, because iteration and clear method are dropped, we can implement WeakMap as an inverted per-object table instead of Ephemerons[3]. The last implementation example shows that my converting realm.[[tempateMap]] into WeakMap proposal can be implemented even if the WeakMap is implemented as an inverted per-object table. Of course, if we take an inverted per-object table, private symbols should be treated specially in the implementation :) 1. we need to carefully extend the object with private symbols even if the object is frozen. 2. private symbols' lookup system should not be trapped by ES6 Proxy. 3. private symbols should not be exposed to users. [1]: https://twitter.com/awbjs/status/535830604269355008 [2]: https://esdiscuss.org/topic/removal-of-weakmap-weakset-clear [3]: http://dl.acm.org/citation.cfm?id=263733 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Named `this` and `this` destructuring
On Jun 17, 2015, at 8:09 AM, Andrea Giammarchi wrote:
Mostly every Array extra in ES5 would work with those functions, e.g.
```js
function multiplyPoints (_p2) {
var { x1: x, y1: y } = this;
var { x2: x, y2: y } = _p2;
return { x: x1 * x2, y: y1 * y2 };
}
var multiplied = manyPoints.map(multiplyPoints, centralPoint);
```
It's not that common pattern but it gives you the ability to recycle
functions as both methods or filters or mappers or forEachers and vice-versa.
I personally use those kind of functions quite a lot to be honest, most
developers keep ignoring Array extra second parameter as context though, they
probably use a wrapped fat arrow within an IFI with call(context) :D
It seems to me that we already can quite nicely express in ES6 the use of a
function as a method:
```js
function multiplyPoints({x1, y1}, {x2,y2}) {
return { x: x1 * x2, y: y1 * y2 }
}
class Point {
multiply(p2) {return multiplyPoints(this, p2)}
}
```
or, perhaps a bit more OO
```js
class Point {
static multiply({x1, y1}, {x2,y2}) {
return new Point(x1 * x2, y1 * y2 ) //or new this(...) if you care about
subclassing Point
}
multiply(p2) {return Point.multiply(this, p2)}
constructor(x,y) {
this.x = x;
this.x = y;
}
}
```
Regardless of how you express it, if you want the same function to be used both
as a standalone function and as an method, you are going to have to have a line
or two of code to install the function as a method. To me, the one-line method
definitions used above are about as concise and much clearer in intent than
`Point.prototype.multiply=multiplyPoints;` or whatever other expression you
would use to install such a function as a method. And I would expect any high
perf JIT to use inlining to completely eliminate the indirection so, where it
matters, there probably wound't be any performance difference.
Many JS programmers have historically been confused about the JS semantics of
`this` because it is over-exposed in non-method functions. Things like the
current proposal increases rather than mitigates the potential for such
confusion. if you are programming in a functional style, don't write functions
that use `this`. If you need to transition from to/from OO and functional
styles, be explicit as shown above.
`this` is an OO concept. FP people, `this` is not for you; don't use it,
don't try to fix it.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Template site objects and WeakMap
On Wed, Jun 17, 2015 at 10:41 PM, Mark Miller erig...@gmail.com wrote:
Hi Yusuke, congratulations and THANK YOU! I learned something important
reading your messages. The notion that we can preserve non-observability
when making one thing a WeakMap iff we make all other WeakMaps be strong
for those same objects is true, novel, and very surprising. I have been
working on such concepts for decades and never come across anything like it.
Thanks for your clarification!
If the target object is resilient (it can be re-generated without an
observable side effects) and immutable, we can inverse strong weak maps.
In this case, strong internal Map is converted into WeakMap and user
exposed WeakMap are converted into strong Map.
The internal map itself cannot be collected, but, user exposed maps can be
collected.
So by inverting them, the target objects become collectable.
In this case, I suspect that implementers will continue to choose the
memory leak rather than make WeakMap more complex in this way. But you have
now given them a choice, which is great! The spec does not need to change
to enable this choice. The spec is only about observable differences, and
the space optimization you suggest would be unobservable.
I'm planning to discuss about this implementation in JavaScriptCore because
I'm an template strings implementor in JavaScriptCore.
BTW, by extending the implementation slightly, we can still preserve
performance optimization.
When generating template site objects at first, generate it, register it to
realm's WeakMap and strongly reference it in the JavaScript code site
instead of realm.
This is the same behavior to that immutable JSStrings are stored and
strongly referenced in the JavaScript code itself.
When the JavaScript code is discarded, we can collect them.
And by slightly modifying the per-object table proposal, we can still
support it with this change ;)
We can define WeakMap as
class WeakMap {
constructor(...) {
this.privateSymbol = @privateSymbol;
this.map = new Map();
}
get(object) {
if (object is template site object) {
return this.map.get(object);
}
return object[this.privateSymbol];
}
set(object, value) {
if (object is template site object) {
this.map.set(object, value);
return this;
}
object[this.privateSymbol] = value;
return this;
}
}
Your observation, being general, may find other applications even if it is
not used to optimize this one. This observation is not language specific;
it may well find application in other memory safe languages including those
yet to be invented. You have added another tool to our toolbox. You have
deepened our understanding of what is possible.
On Tue, Jun 16, 2015 at 10:45 PM, Yusuke SUZUKI utatane@gmail.com
wrote:
On Wed, Jun 17, 2015 at 2:29 PM, Yusuke SUZUKI utatane@gmail.com
wrote:
Thanks. And sorry for the late reply.
On Wed, Jun 17, 2015 at 11:31 AM, Mark S. Miller erig...@google.com
wrote:
Hi Yusuke, I am not sure I understood your message. Could you show some
example code that would observe the observable difference you have in mind?
On Tue, Jun 16, 2015 at 7:25 PM, Yusuke SUZUKI utatane@gmail.com
wrote:
Hi forks,
In ES6 spec, template site objects are strongly referenced by the
realm.[[templateMap]].
So naive implementation leaks memory because it keeps all the site
objects in the realm.
To lookup the identical template site objects, template site objects are
stored in the realm.[[templateMap]].
So they are strongly referenced and the naive implementation leaks
memory.
// By writing the following code, we can leak memory that GC cannot
collect.
function tag(siteObject)
{
return siteObject;
}
for (var i = 0;; ++i) {
eval(tag` + i + `);
}
However, we can alleviate this situation.
Because template site objects are frozen completely, it behaves as if
it's a primitive value.
It enables the implementation to reference it from the realm weakly.
When all disclosed site objects are not referenced, we can GC them because
nobody knows the given site object is once collected ( re-generated).
By implementing the realm.[[templateMap]] as WeakMap, we can alleviate
this situation.
function tag(siteObject) {
// Since siteObject is frozen, we cannot attach a property to it.
// So if nobody has the reference to the siteObject, we can collect
this siteObject since identity can not be tested across already collected
newly created site object.
}
But, even if the object is frozen, we can bind the property with it
indirectly by using WeakMap.
As a result, if the site objects are referenced by the realm weakly,
users can observe it by using WeakMap.
var map = new WeakMap();
function tag(siteObject) {
return siteObject;
}
var siteObject = tag`hello`;
map.set(siteObject, true);
gc(); // If
Re: Template site objects and WeakMap
[+Allen] Can registered Symbols be used as keys in WeakMaps? If so, we have a fatal unauthorized communications channel that we need to fix in the spec asap! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
