Re: has the syntax for proxies been finalized ?
Proxy.create and Proxy.createFunction are deprecated.
The correct syntax is `new Proxy(target, handler)`
In my original direct proxies proposal, the `new` was optional, so that
`var p = Proxy(target, handler)` works equally well (cf.
http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies)
Since then, it seems people want to move away from implicit construction
(since it doesn't interact well with class inheritance), so I don't know if
there is still consensus on this.
In the prototype Firefox implementation, `new` is currently mandatory.
Regards,
Tom
2013/10/18 Angus Croll anguscr...@gmail.com
I couldn't find a commitment to a specific syntax in the latest ES6
standard
Gecko, chrome experimental, traceur and 'node --harmony-proxies' support
the Proxy.create syntax (detailed in
http://wiki.ecmascript.org/doku.php?id=harmony:proxies)
e.g.
var proxy = Proxy.create({
get: function(p, n) {
return 'Hello ' + n;
}
});
proxy.World //'Hello World'
However MDN calls the above the 'Old Proxy API'.
Gecko also supports what MDN indicates implies is the current Proxy
syntax (i.e. new Proxy)
e.g.
var p = new Proxy(
{},
{get: function(p,x) {
return 'Hello ' + x
}}
);
p.World; //'Hello World'
Which is right?
thanks
@angustweets
___
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
`String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
ES6 fixes `String.fromCharCode` by introducing `String.fromCodePoint`. Similarly, `String.prototype.charCodeAt` is fixed by `String.prototype.codePointAt`. Should there be a method that is like `String.prototype.charAt` except it deals with astral Unicode symbols wherever possible? '팆'.charAt(0) // U+1D306 '\uD834' // the first surrogate half for U+1D306 '팆'.symbolAt(0) // U+1D306 '팆' // U+1D306 Has this been discussed before? If there’s any interest I’d be happy to create a strawman. Mathias http://mathiasbynens.be/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: has the syntax for proxies been finalized ?
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Angus Croll I couldn't find a commitment to a specific syntax in the latest ES6 standard It's not quite fleshed out yet, but the constructor function is at least there: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-objects ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: has the syntax for proxies been finalized ?
Le 18/10/2013 07:19, Angus Croll a écrit :
I couldn't find a commitment to a specific syntax in the latest ES6
standard
The latest official news is in the May 2013 TC39 notes:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-05/may-21.md#44-proxies
The final design of proxies is the direct proxies design. As Tom said,
a proxy is now created doing:
var p = Proxy(target, handler)
Proxy.create and Proxy.createFunction are aimed at disappearing.
Gecko, chrome experimental, traceur and 'node
--harmony-proxies' support the Proxy.create syntax (detailed in
http://wiki.ecmascript.org/doku.php?id=harmony:proxies)
e.g.
var proxy = Proxy.create({
get: function(p, n) {
return 'Hello ' + n;
}
});
proxy.World //'Hello World'
On the SpiderMonkey (Gecko implements the DOM and other platform APIs
and SpiderMonkey is the part that implement ECMAScript) side, I filed a
bug to get rid of these as it's indeed confusing to have both APIs
exposed in web pages:
https://bugzilla.mozilla.org/show_bug.cgi?id=892903
IIRC, the V8 team had started implementing something (behind a flag),
and then wars on Proxy design happened, so they chose to wait for the
design to stabilize. Now may be a good time to restart
However MDN calls the above the 'Old Proxy API'.
I'm glad I succeeded in, at least, making people wonder what that was
all about :-)
Since I've been following closely the design of proxies, I documented
them on MDN. Especially after the implementation of direct proxies in
Firefox (where I moved the documentation of the previous API to its own
page and try to explain the best I could that people should not use it).
I'm happy to improve the doc if something isn't clear (on the feature
itself or clarify the current technico-social mess of different APIs in
the wild).
As a side note, to my knowledge, the only native implementation of
direct proxies is in Firefox, but it's incomplete and has known bugs.
You can see the known limitations and bugs here:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=703537hide_resolved=1
(depends on section. Bug 787710 is particularly funny :-)).
If you want to play with proxies, I think that the most
faithful-to-the-spec implementation is Tom's polyfill:
https://github.com/tvcutsem/harmony-reflect/blob/master/reflect.js where
he's using the old API where available to implement the new one.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Fri, Oct 18, 2013 at 8:46 AM, Mathias Bynens math...@qiwi.be wrote: ES6 fixes `String.fromCharCode` by introducing `String.fromCodePoint`. Similarly, `String.prototype.charCodeAt` is fixed by `String.prototype.codePointAt`. Should there be a method that is like `String.prototype.charAt` except it deals with astral Unicode symbols wherever possible? '팆'.charAt(0) // U+1D306 '\uD834' // the first surrogate half for U+1D306 '팆'.symbolAt(0) // U+1D306 '팆' // U+1D306 I think the idea is good, but the name may be confusing with regard to Symbols (maybe not?) Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On 18 Oct 2013, at 09:21, Rick Waldron waldron.r...@gmail.com wrote: I think the idea is good, but the name may be confusing with regard to Symbols (maybe not?) Yeah, I thought about that, but couldn’t figure out a better name. “Glyph” or “Grapheme” wouldn’t be accurate. Any suggestions? Anyway, if everyone agrees this is a good idea I’ll get started on fleshing out a proposal. We can then use this thread to bikeshed about the name. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: has the syntax for proxies been finalized ?
Great info thanks (and Tom and Domenic)
A note on MDN confirming that direct proxy adhered to the new spec (and a
similar one on old proxy saying it didn't) would probably be immensely helpful
to other people who had the same question I had.
Also (to all) deleting or marking as obsolete all wiki-harmony docs that no
longer meet the standard would save a lot of wasted hours
thanks!
On Oct 18, 2013, at 6:17, David Bruant bruan...@gmail.com wrote:
Le 18/10/2013 07:19, Angus Croll a écrit :
I couldn't find a commitment to a specific syntax in the latest ES6 standard
The latest official news is in the May 2013 TC39 notes:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-05/may-21.md#44-proxies
The final design of proxies is the direct proxies design. As Tom said, a
proxy is now created doing:
var p = Proxy(target, handler)
Proxy.create and Proxy.createFunction are aimed at disappearing.
Gecko, chrome experimental, traceur and 'node --harmony-proxies' support the
Proxy.create syntax (detailed in
http://wiki.ecmascript.org/doku.php?id=harmony:proxies)
e.g.
var proxy = Proxy.create({
get: function(p, n) {
return 'Hello ' + n;
}
});
proxy.World //'Hello World'
On the SpiderMonkey (Gecko implements the DOM and other platform APIs and
SpiderMonkey is the part that implement ECMAScript) side, I filed a bug to
get rid of these as it's indeed confusing to have both APIs exposed in web
pages:
https://bugzilla.mozilla.org/show_bug.cgi?id=892903
IIRC, the V8 team had started implementing something (behind a flag), and
then wars on Proxy design happened, so they chose to wait for the design to
stabilize. Now may be a good time to restart
However MDN calls the above the 'Old Proxy API'.
I'm glad I succeeded in, at least, making people wonder what that was all
about :-)
Since I've been following closely the design of proxies, I documented them on
MDN. Especially after the implementation of direct proxies in Firefox
(where I moved the documentation of the previous API to its own page and try
to explain the best I could that people should not use it). I'm happy to
improve the doc if something isn't clear (on the feature itself or
clarify the current technico-social mess of different APIs in the wild).
As a side note, to my knowledge, the only native implementation of direct
proxies is in Firefox, but it's incomplete and has known bugs. You can
see the known limitations and bugs here:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=703537hide_resolved=1
(depends on section. Bug 787710 is particularly funny :-)).
If you want to play with proxies, I think that the most faithful-to-the-spec
implementation is Tom's polyfill:
https://github.com/tvcutsem/harmony-reflect/blob/master/reflect.js where he's
using the old API where available to implement the new one.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: has the syntax for proxies been finalized ?
From: es-discuss [es-discuss-boun...@mozilla.org] on behalf of Angus Croll [anguscr...@gmail.com Also (to all) deleting or marking as obsolete all wiki-harmony docs that no longer meet the standard would save a lot of wasted hours I know Rick has already made strides in that direction via warnings like This API is superseded by the newer direct proxies API. or This proposal has progressed to the Draft ECMAScript 6 Specification (Sept. 2013 draft Sections 9.3 and 26.2), which is available for review here: specification_drafts. Any new issues relating to them should be filed as bugs at http://bugs.ecmascript.org. The content on this page is for historic record only and may no longer reflect the current state of the feature described within. But I somewhat agree that the warnings are not scary enough. Something drastic like moving the entire page to obsolete:proxies would be nice. But, eh, broken links :-/. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: has the syntax for proxies been finalized ?
I can confirm:
npm install harmony-reflect
node --harmony
require('harmony-reflect')
and I'm good to go with ES6 proxy syntax
thanks all!
@angustweets
On Fri, Oct 18, 2013 at 7:49 AM, Angus Croll anguscr...@gmail.com wrote:
Great info thanks (and Tom and Domenic)
A note on MDN confirming that direct proxy adhered to the new spec (and a
similar one on old proxy saying it didn't) would probably be immensely
helpful to other people who had the same question I had.
Also (to all) deleting or marking as obsolete all wiki-harmony docs that
no longer meet the standard would save a lot of wasted hours
thanks!
On Oct 18, 2013, at 6:17, David Bruant bruan...@gmail.com wrote:
Le 18/10/2013 07:19, Angus Croll a écrit :
I couldn't find a commitment to a specific syntax in the latest ES6
standard
The latest official news is in the May 2013 TC39 notes:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-05/may-21.md#44-proxies
The final design of proxies is the direct proxies design. As Tom said, a
proxy is now created doing:
var p = Proxy(target, handler)
Proxy.create and Proxy.createFunction are aimed at disappearing.
Gecko, chrome experimental, traceur and 'node --harmony-proxies' support
the Proxy.create syntax (detailed in
http://wiki.ecmascript.org/doku.php?id=harmony:proxies)
e.g.
var proxy = Proxy.create({
get: function(p, n) {
return 'Hello ' + n;
}
});
proxy.World //'Hello World'
On the SpiderMonkey (Gecko implements the DOM and other platform APIs and
SpiderMonkey is the part that implement ECMAScript) side, I filed a bug to
get rid of these as it's indeed confusing to have both APIs exposed in web
pages:
https://bugzilla.mozilla.org/show_bug.cgi?id=892903
IIRC, the V8 team had started implementing something (behind a flag), and
then wars on Proxy design happened, so they chose to wait for the design to
stabilize. Now may be a good time to restart
However MDN calls the above the 'Old Proxy API'.
I'm glad I succeeded in, at least, making people wonder what that was all
about :-)
Since I've been following closely the design of proxies, I documented them
on MDN. Especially after the implementation of direct proxies in Firefox
(where I moved the documentation of the previous API to its own page and
try to explain the best I could that people should not use it). I'm happy
to improve the doc if something isn't clear (on the feature itself or
clarify the current technico-social mess of different APIs in the wild).
As a side note, to my knowledge, the only native implementation of direct
proxies is in Firefox, but it's incomplete and has known bugs. You can see
the known limitations and bugs here:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=703537hide_resolved=1(depends
on section. Bug 787710 is particularly funny :-)).
If you want to play with proxies, I think that the most
faithful-to-the-spec implementation is Tom's polyfill:
https://github.com/tvcutsem/harmony-reflect/blob/master/reflect.js where
he's using the old API where available to implement the new one.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
I also noticed the naming similarity to ES6 `Symbol`s. I've seen people fill `String.prototype.getFullChar` before and similarly things like `String.prototype.fromFullCharCode` for dealing with surrogates before. I like `String.prototype.signAt` but I haven't seen it used before. I'm eager to hear what Allen has to say about this given his work on unicode in ecmascript. Especially how it settles with this http://wiki.ecmascript.org/doku.php?id=strawman:support_full_unicode_in_stringsrev=1304034700 I also think that this is important enough to be there. -- Forwarded message -- From: Mathias Bynens math...@qiwi.be To: Rick Waldron waldron.r...@gmail.com Cc: es-discuss@mozilla.org list es-discuss@mozilla.org Date: Fri, 18 Oct 2013 09:47:21 -0500 Subject: Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`) On 18 Oct 2013, at 09:21, Rick Waldron waldron.r...@gmail.com wrote: I think the idea is good, but the name may be confusing with regard to Symbols (maybe not?) Yeah, I thought about that, but couldn’t figure out a better name. “Glyph” or “Grapheme” wouldn’t be accurate. Any suggestions? Anyway, if everyone agrees this is a good idea I’ll get started on fleshing out a proposal. We can then use this thread to bikeshed about the name. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: has the syntax for proxies been finalized ?
On Fri, Oct 18, 2013 at 10:53 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss [es-discuss-boun...@mozilla.org] on behalf of Angus Croll [anguscr...@gmail.com Also (to all) deleting or marking as obsolete all wiki-harmony docs that no longer meet the standard would save a lot of wasted hours @Angus, I'm sorry this happened, I try to keep up with marking wiki docs' status as best as I can. I know Rick has already made strides in that direction via warnings like This API is superseded by the newer direct proxies API. or This proposal has progressed to the Draft ECMAScript 6 Specification (Sept. 2013 draft Sections 9.3 and 26.2), which is available for review here: specification_drafts. Any new issues relating to them should be filed as bugs at http://bugs.ecmascript.org. The content on this page is for historic record only and may no longer reflect the current state of the feature described within. But I somewhat agree that the warnings are not scary enough. Something drastic like moving the entire page to obsolete:proxies would be nice. But, eh, broken links :-/. I'm all for suggestions to make it _even_ _more_ _clear_, as long as those suggestions don't break links (as Domenic has mentioned here). Currently, the old proxy proposals are stricken on the harmony:proposals page and the direct proxies proposal includes the progressed to draft text. FWIW, I've added The content on this page is OBSOLETE to the three oldest proxy proposals. @Tom - since you know the status of the more recent Proxy wiki pages better than I do, would you mind adding the same h1 text to those that fit the description of obsolete? Thanks! Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
Here’s my proposal. Feedback welcome, as well as suggestions for a better name (if any). ## String.prototype.symbolAt(pos) NOTE: Returns a single-element String containing the code point at element position `pos` in the String `value` resulting from converting the `this` object to a String. If there is no element at that position, the result is the empty String. The result is a String value, not a String object. When the `symbolAt` method is called with one argument `pos`, the following steps are taken: 01. Let `O` be `CheckObjectCoercible(this value)`. 02. Let `S` be `ToString(O)`. 03. `ReturnIfAbrupt(S)`. 04. Let `position` be `ToInteger(pos)`. 05. `ReturnIfAbrupt(position)`. 06. Let `size` be the number of elements in `S`. 07. If `position 0` or `position ≥ size`, return the empty String. 08. Let `first` be the code unit at index `position` in the String `S`. 09. Let `cuFirst` be the code unit value of the element at index `0` in the String `first`. 10. If `cuFirst 0xD800` or `cuFirst 0xDBFF` or `position + 1 = size`, then return `first`. 11. Let `cuSecond` be the code unit value of the element at index `position + 1` in the String `S`. 12. If `cuSecond 0xDC00` or `cuSecond 0xDFFF`, then return `first`. 13. Let `second` be the code unit at index `position + 1` in the string `S`. 14. Let `cp` be `(first – 0xD800) × 0x400 + (second – 0xDC00) + 0x1`. 15. Return the elements of the UTF-16 Encoding (clause 6) of `cp`. NOTE: The `symbolAt` function is intentionally generic; it does not require that its `this` value be a String object. Therefore it can be transferred to other kinds of objects for use as a method. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Fri, Oct 18, 2013 at 10:47 AM, Mathias Bynens math...@qiwi.be wrote: On 18 Oct 2013, at 09:21, Rick Waldron waldron.r...@gmail.com wrote: I think the idea is good, but the name may be confusing with regard to Symbols (maybe not?) Yeah, I thought about that, but couldn’t figure out a better name. “Glyph” or “Grapheme” wouldn’t be accurate. Any suggestions? Anyway, if everyone agrees this is a good idea I’ll get started on fleshing out a proposal. We can then use this thread to bikeshed about the name. I think it's worthwhile to write up a proposal. And the shed should always be pink ;) Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: has the syntax for proxies been finalized ?
No worries guys - thanks for adding the 'obsolete' note @angustweets On Fri, Oct 18, 2013 at 8:13 AM, Rick Waldron waldron.r...@gmail.comwrote: On Fri, Oct 18, 2013 at 10:53 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss [es-discuss-boun...@mozilla.org] on behalf of Angus Croll [anguscr...@gmail.com Also (to all) deleting or marking as obsolete all wiki-harmony docs that no longer meet the standard would save a lot of wasted hours @Angus, I'm sorry this happened, I try to keep up with marking wiki docs' status as best as I can. I know Rick has already made strides in that direction via warnings like This API is superseded by the newer direct proxies API. or This proposal has progressed to the Draft ECMAScript 6 Specification (Sept. 2013 draft Sections 9.3 and 26.2), which is available for review here: specification_drafts. Any new issues relating to them should be filed as bugs at http://bugs.ecmascript.org. The content on this page is for historic record only and may no longer reflect the current state of the feature described within. But I somewhat agree that the warnings are not scary enough. Something drastic like moving the entire page to obsolete:proxies would be nice. But, eh, broken links :-/. I'm all for suggestions to make it _even_ _more_ _clear_, as long as those suggestions don't break links (as Domenic has mentioned here). Currently, the old proxy proposals are stricken on the harmony:proposals page and the direct proxies proposal includes the progressed to draft text. FWIW, I've added The content on this page is OBSOLETE to the three oldest proxy proposals. @Tom - since you know the status of the more recent Proxy wiki pages better than I do, would you mind adding the same h1 text to those that fit the description of obsolete? Thanks! Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
[[Invoke]] and implicit method calls, once more
I can't remember the conclusion of the earlier thread on this topic. The question was about how implicit method calls should interact with proxies in places (like [ToPrimitive](http://people.mozilla.org/~jorendorff/es6-draft.html#sec-toprimitive)) where the spec first checks that the desired method exists and is callable, then calls it. I seem to recall the result was either: 1. don't change anything; or 2. change those places to do [[Get]], if IsCallable, [[Invoke]] instead of [[Get]], if IsCallable, [[Call]]. but the thread sort of trailed off. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: has the syntax for proxies been finalized ?
On Fri, Oct 18, 2013 at 11:19 AM, Angus Croll anguscr...@gmail.com wrote: No worries guys - thanks for adding the 'obsolete' note Don't hesitate to ask for clarification on this list—especially if you think it will save you time :) Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Fri, Oct 18, 2013 at 11:15 AM, Mathias Bynens math...@qiwi.be wrote: Here’s my proposal. Feedback welcome, as well as suggestions for a better name (if any). ## String.prototype.symbolAt(pos) Here goes... String.prototype.elementAt? Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
Doesn't Unicode have some name for visual representation of a code point? Maybe it's symbol? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Fri, Oct 18, 2013 at 1:46 PM, Mathias Bynens math...@qiwi.be wrote: Similarly, `String.prototype.charCodeAt` is fixed by `String.prototype.codePointAt`. When you phrase it like that, I see another problem with codePointAt(). You can't just replace existing usage of charCodeAt() with codePointAt() as that would fail for input with paired surrogates. E.g. a simple loop over a string that prints code points would print both the code point and the trail surrogate code point for a surrogate pair. The same goes for this new method. I still think that only offering a better way to iterate strings (as planned) seems like a much safer start into this brave new code point-based world. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On 18 Oct 2013, at 10:48, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Oct 18, 2013 at 1:46 PM, Mathias Bynens math...@qiwi.be wrote: Similarly, `String.prototype.charCodeAt` is fixed by `String.prototype.codePointAt`. When you phrase it like that, I see another problem with codePointAt(). You can't just replace existing usage of charCodeAt() with codePointAt() as that would fail for input with paired surrogates. E.g. a simple loop over a string that prints code points would print both the code point and the trail surrogate code point for a surrogate pair. I disagree. In those situations you should just iterate over the string using `for…of`. `.symbolAt()` can be a useful replacement for `.charAt()` in case you only need to get the first symbol in the string. The same goes for `.codePointAt()` vs. `.charCodeAt()`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Fri, Oct 18, 2013 at 11:53 AM, Mathias Bynens math...@qiwi.be wrote: On 18 Oct 2013, at 10:25, Rick Waldron waldron.r...@gmail.com wrote: String.prototype.elementAt? This may be confusing too, since the spec refers to `elements` as code units, not code points. Yes, slight mis-reading of your proposal—thanks for clarifying Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Fri, Oct 18, 2013 at 4:58 PM, Mathias Bynens math...@qiwi.be wrote: On 18 Oct 2013, at 10:48, Anne van Kesteren ann...@annevk.nl wrote: When you phrase it like that, I see another problem with codePointAt(). You can't just replace existing usage of charCodeAt() with codePointAt() as that would fail for input with paired surrogates. E.g. a simple loop over a string that prints code points would print both the code point and the trail surrogate code point for a surrogate pair. I disagree. In those situations you should just iterate over the string using `for…of`. That seems to iterate over code units as far as I can tell. for (var x of ) print(x.charCodeAt(0)) invokes print() twice in Gecko. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
/ I disagree. In those situations you should just iterate over the string using `for...of`. / That seems to iterate over code units as far as I can tell. for (var x of ?) print(x.charCodeAt(0)) invokes print() twice in Gecko. SpiderMonkey does not implement the (yet to be) spec'ed String.prototype.@@iterator function, instead it simply aliases String.prototype[@@iterator] to Array.prototype[@@iterator]: js String.prototype[@@iterator] === Array.prototype[@@iterator] true - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: has the syntax for proxies been finalized ?
Follow up question for Tom et al...
Using require('harmony-reflect')
var t = {a:3, c:4};
var p = Proxy(
t,
{
get: function() {},
delete: function(t,x) {
console.log('deleting');
delete t.a;
}
}
);
delete p.c
p; //{a:3}
t; //{a:3}
the console.log is not called and deleting is not trapped.
Am I doing something wrong?
@angustweets
On Fri, Oct 18, 2013 at 12:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
Proxy.create and Proxy.createFunction are deprecated.
The correct syntax is `new Proxy(target, handler)`
In my original direct proxies proposal, the `new` was optional, so that
`var p = Proxy(target, handler)` works equally well (cf.
http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies)
Since then, it seems people want to move away from implicit construction
(since it doesn't interact well with class inheritance), so I don't know if
there is still consensus on this.
In the prototype Firefox implementation, `new` is currently mandatory.
Regards,
Tom
2013/10/18 Angus Croll anguscr...@gmail.com
I couldn't find a commitment to a specific syntax in the latest ES6
standard
Gecko, chrome experimental, traceur and 'node --harmony-proxies' support
the Proxy.create syntax (detailed in
http://wiki.ecmascript.org/doku.php?id=harmony:proxies)
e.g.
var proxy = Proxy.create({
get: function(p, n) {
return 'Hello ' + n;
}
});
proxy.World //'Hello World'
However MDN calls the above the 'Old Proxy API'.
Gecko also supports what MDN indicates implies is the current Proxy
syntax (i.e. new Proxy)
e.g.
var p = new Proxy(
{},
{get: function(p,x) {
return 'Hello ' + x
}}
);
p.World; //'Hello World'
Which is right?
thanks
@angustweets
___
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: has the syntax for proxies been finalized ?
Follow up question for Tom et al...
Using require('harmony-reflect')
var t = {a:3, c:4};
var p = Proxy(
t,
{
get: function() {},
delete: function(t,x) {
console.log('deleting');
delete t.a;
}
}
);
delete p.c
p; //{a:3}
t; //{a:3}
the console.log is not called and deleting is not trapped.
Am I doing something wrong?
The trap name for the `delete` operator is deleteProperty instead of
delete...
@angustweets
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Oct 18, 2013, at 7:21 AM, Rick Waldron wrote:
On Fri, Oct 18, 2013 at 8:46 AM, Mathias Bynens math...@qiwi.be wrote:
ES6 fixes `String.fromCharCode` by introducing `String.fromCodePoint`.
Similarly, `String.prototype.charCodeAt` is fixed by
`String.prototype.codePointAt`.
Should there be a method that is like `String.prototype.charAt` except it
deals with astral Unicode symbols wherever possible?
'팆'.charAt(0) // U+1D306
'\uD834' // the first surrogate half for U+1D306
'팆'.symbolAt(0) // U+1D306
'팆' // U+1D306
I think the idea is good, but the name may be confusing with regard to
Symbols (maybe not?)
Given that we have charAt, charCodeAt and codePointAt, I think the most
appropiate name for such a method would be 'at':
'팆'.at(0)
The issue when this sort of method has been discussed in the past has been what
to do when you index at a trailing surrogate possition:
'팆'.at(1)
do you still get '팆' or do you get the equivalent of
String.fromCharCode('팆'[1]) ?
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Oct 18, 2013, at 9:05 AM, Anne van Kesteren wrote: On Fri, Oct 18, 2013 at 4:58 PM, Mathias Bynens math...@qiwi.be wrote: On 18 Oct 2013, at 10:48, Anne van Kesteren ann...@annevk.nl wrote: When you phrase it like that, I see another problem with codePointAt(). You can't just replace existing usage of charCodeAt() with codePointAt() as that would fail for input with paired surrogates. E.g. a simple loop over a string that prints code points would print both the code point and the trail surrogate code point for a surrogate pair. I disagree. In those situations you should just iterate over the string using `for…of`. That seems to iterate over code units as far as I can tell. for (var x of ) print(x.charCodeAt(0)) invokes print() twice in Gecko. No that's not correct, the @@iterator method of String.prototype is supposed to returns an interator the iterates code points and returns single codepoint strings. The spec. for this will be in the next draft that I release. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
+1 for the simplified `at(symbolIndex)`
I would expect '팆'.at(1) to fail same way 'a'.charAt(1) or
'a'.charCodeAt(1) would.
I would expect '팆'.at(symbolIndex) to behave as `length` does based on
unique symbol (unicode extra) so that everyone, except RAM and CPU, will
have life easier with strings.
Long story short: there's no symbol at 1, the symbol is at 0 because the
size of that unicode string is 1
That said, I am sure the discussion went through this already ^_^
On Fri, Oct 18, 2013 at 9:57 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Oct 18, 2013, at 7:21 AM, Rick Waldron wrote:
On Fri, Oct 18, 2013 at 8:46 AM, Mathias Bynens math...@qiwi.be wrote:
ES6 fixes `String.fromCharCode` by introducing `String.fromCodePoint`.
Similarly, `String.prototype.charCodeAt` is fixed by
`String.prototype.codePointAt`.
Should there be a method that is like `String.prototype.charAt` except it
deals with astral Unicode symbols wherever possible?
'팆'.charAt(0) // U+1D306
'\uD834' // the first surrogate half for U+1D306
'팆'.symbolAt(0) // U+1D306
'팆' // U+1D306
I think the idea is good, but the name may be confusing with regard to
Symbols (maybe not?)
Given that we have charAt, charCodeAt and codePointAt, I think the most
appropiate name for such a method would be 'at':
'팆'.at(0)
The issue when this sort of method has been discussed in the past has been
what to do when you index at a trailing surrogate possition:
'팆'.at(1)
do you still get '팆' or do you get the equivalent of
String.fromCharCode('팆'[1]) ?
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: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
the size of that unicode string is 1 ... meaning the **virtual** size for
human eyes
On Fri, Oct 18, 2013 at 10:06 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
+1 for the simplified `at(symbolIndex)`
I would expect '팆'.at(1) to fail same way 'a'.charAt(1) or
'a'.charCodeAt(1) would.
I would expect '팆'.at(symbolIndex) to behave as `length` does based on
unique symbol (unicode extra) so that everyone, except RAM and CPU, will
have life easier with strings.
Long story short: there's no symbol at 1, the symbol is at 0 because the
size of that unicode string is 1
That said, I am sure the discussion went through this already ^_^
On Fri, Oct 18, 2013 at 9:57 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Oct 18, 2013, at 7:21 AM, Rick Waldron wrote:
On Fri, Oct 18, 2013 at 8:46 AM, Mathias Bynens math...@qiwi.be wrote:
ES6 fixes `String.fromCharCode` by introducing `String.fromCodePoint`.
Similarly, `String.prototype.charCodeAt` is fixed by
`String.prototype.codePointAt`.
Should there be a method that is like `String.prototype.charAt` except
it deals with astral Unicode symbols wherever possible?
'팆'.charAt(0) // U+1D306
'\uD834' // the first surrogate half for U+1D306
'팆'.symbolAt(0) // U+1D306
'팆' // U+1D306
I think the idea is good, but the name may be confusing with regard to
Symbols (maybe not?)
Given that we have charAt, charCodeAt and codePointAt, I think the most
appropiate name for such a method would be 'at':
'팆'.at(0)
The issue when this sort of method has been discussed in the past has
been what to do when you index at a trailing surrogate possition:
'팆'.at(1)
do you still get '팆' or do you get the equivalent of
String.fromCharCode('팆'[1]) ?
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: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
if this is true then .at(symbolIndex) should be a no-brain ?
```
var virtualLength = 0;
for (var x of ) {
virtualLength++;
}
// equivalent of
for(var i = 0; i virtualLength; i++) {
.at(i);
}
```
Am I missing something ?
On Fri, Oct 18, 2013 at 10:03 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Oct 18, 2013, at 9:05 AM, Anne van Kesteren wrote:
On Fri, Oct 18, 2013 at 4:58 PM, Mathias Bynens math...@qiwi.be wrote:
On 18 Oct 2013, at 10:48, Anne van Kesteren ann...@annevk.nl wrote:
When you phrase it like that, I see another problem with
codePointAt(). You can't just replace existing usage of charCodeAt()
with codePointAt() as that would fail for input with paired
surrogates. E.g. a simple loop over a string that prints code points
would print both the code point and the trail surrogate code point for
a surrogate pair.
I disagree. In those situations you should just iterate over the string
using `for…of`.
That seems to iterate over code units as far as I can tell.
for (var x of )
print(x.charCodeAt(0))
invokes print() twice in Gecko.
No that's not correct, the @@iterator method of String.prototype is
supposed to returns an interator the iterates code points and returns
single codepoint strings.
The spec. for this will be in the next draft that I release.
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: has the syntax for proxies been finalized ?
thanks André that works!
(I was going by
https://github.com/tvcutsem/harmony-reflect/blob/master/doc/traps.md which
says 'delete')
@angustweets
On Fri, Oct 18, 2013 at 9:38 AM, André Bargull andre.barg...@udo.eduwrote:
Follow up question for Tom et al...
Using require('harmony-reflect')
var t = {a:3, c:4};
var p = Proxy(
t,
{
get: function() {},
delete: function(t,x) {
console.log('deleting');
delete t.a;
}
}
);
delete p.c
p; //{a:3}
t; //{a:3}
the console.log is not called and deleting is not trapped.
Am I doing something wrong?
The trap name for the `delete` operator is deleteProperty instead of
delete...
@angustweets
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: has the syntax for proxies been finalized ?
On Oct 18, 2013, at 12:33 AM, Tom Van Cutsem wrote: Proxy.create and Proxy.createFunction are deprecated. The correct syntax is `new Proxy(target, handler)` In my original direct proxies proposal, the `new` was optional, so that `var p = Proxy(target, handler)` works equally well (cf. http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies) Since then, it seems people want to move away from implicit construction (since it doesn't interact well with class inheritance), so I don't know if there is still consensus on this. In the prototype Firefox implementation, `new` is currently mandatory. Regards, Tom This is what I currently have in my working draft of the ES6 spec: 26.2.1 The Proxy Factory Function 26.2.1.1Proxy ( target, handler) The Proxy function is used to create an irrevocable Proxy object When Proxy is called with arguments target and handler the following steps are taken: 1. Let p be ProxyCreate(target, handler). 2. Return p. 26.2.2 Properties of the Proxy Factory Function 26.2.2.1Proxy.revocable ( target, handler ) The Proxy.revocable function takes two arguments target and handler, and performs the following: The Proxy.revocable function is used to create a revocable Proxy object When Proxy.revocable is called with arguments target and handler the following steps are taken: 1. Let p be ProxyCreate(target, handler). 2. ReturnIfAbrupt(p). 3. Let revoker be a new built-in function object as defined in 26.2.2.1.1. 4. Set the [[RevokableProxy]] internal slot of revoker to p. 5. Let result be the result of ObjectCreate(). 6. CreateOwnDataProperty(result, proxy, p). 7. CreateOwnDataProperty(result, revoke, revoker). 8. Return result. 26.2.2.1.1 Proxy Revocation Functions A Proxy revocation function is an anonymous function that has the ability to invalidate a specific Proxy object. Each Proxy revocation function has a [[RevokableProxy]] internal slot. When a Proxy revocation function, F, is called the following steps are taken: 1. Let p be the value of F’s [[RevokableProxy]] internal slot. 2. If p is undefined, then return undefined. 3. Set the value of F’s [[RevokableProxy]] internal slot to undefined. 4. Assert: p is a Proxy object. 5. Set the [[ProxyTarget]] internal slot of p to undefined. 6. Set the [[ProxyHandler]] internal slot of p to undefined. 7. Return undefined. In other words: you can say: Proxy(traget,handler) but not new Proxy(target, handler) It would be easy enough to allow new Proxy(target,handler) but I'm not sure it is the best way to expose the Proxy abstraction . Proxy really isn't a class. There is no Proxy.prototype object and obj instanceof Proxy isn't useful. Also the @@create protocol really isn't right for instantiating Proxies. Subclassing a Proxy isn't going to give you anything that is useful. I think we're now in a position where it would be reasonable to say that 'new is the preferred way to instantiate instances of class-like constructors. Object that represent other kinds of abstractions shouldn't be created using 'new' but instead should be created with a simple function call (arguably, Symbol is another example where we allow Symbol() but not new Symbol()). So, I'd prefer to go with what I've currently specified, but if the concensus is for 'new' I will change it. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Oct 18, 2013, at 10:06 AM, Andrea Giammarchi wrote:
+1 for the simplified `at(symbolIndex)`
I would expect '팆'.at(1) to fail same way 'a'.charAt(1) or 'a'.charCodeAt(1)
would.
They are comparable, as the 'a' example are index out of bounds errors. We
only use code unit indices with strings so '팆'[1] is valid (and so presumably
should be '팆'.at(1) with 1 having the same meaning in each case.
The most consistent way to define String.prototype.at be be:
String.prototype.at = function(pos} {
let cp = this.codePointAt(pos);
return cp===undefined ? undefined : String.fromCodePoint(cp)
}
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [[Invoke]] and implicit method calls, once more
On Oct 18, 2013, at 8:24 AM, Jason Orendorff wrote: I can't remember the conclusion of the earlier thread on this topic. The question was about how implicit method calls should interact with proxies in places (like [ToPrimitive](http://people.mozilla.org/~jorendorff/es6-draft.html#sec-toprimitive)) where the spec first checks that the desired method exists and is callable, then calls it. I seem to recall the result was either: 1. don't change anything; or 2. change those places to do [[Get]], if IsCallable, [[Invoke]] instead of [[Get]], if IsCallable, [[Call]]. but the thread sort of trailed off. Tom, Mark and I has a private conversation about this and some related issues. Mark made some strong points: On Sep 24, 2013, at 12:48 PM, Mark Miller wrote: ... We've said from the beginning that Proxies are not intended as an API to be used directly by non-experts. We've said that it is to be used by experts to create simpler abstractions (like membranes and caretakers) to be used by non-experts. Where we're getting into trouble is * trying to make the API itself directly usable by non-experts. * trying to make the abstraction less leaky for non-membrane use cases where it will necessarily be somewhat leaky anyway. ... What your question does help me be more decisive on: We should not be in a rush to add an Invoke, InvokeFunction, or any new traps not needed for membranes, and not subject to a long history of examination. Invoke at least, as a derived trap, can always be added later, after ES6. As for the handler hierarchy, I don't yet have an opinion about postponing some of this, but perhaps. We should certainly look at it again with such postponement in mind. and this message is a good summary of conclusions that we could agree on: On Sep 25, 2013, at 1:30 AM, Tom Van Cutsem wrote: However, I'm also sympathetic to your argument of keeping the current design minimal, allowing us to extend where necessary based on experience. Specifically w.r.t. the 3 points you mention: * I agree we can postpone the invoke() trap. It can be added later, perhaps in another form. * I agree we can postpone the Handler hierarchy, for the following reasons: - This is a fairly large API design. We have many subtle knobs to turn, and we don't yet know which ones will turn out to be the most important. - We should give the community the opportunity to experiment before settling on a standardized API. - All the code in the proposed Handler API can be fully self-hosted (I have a working implementation on GitHub). * Revocable proxies we should keep. Without them, you can't build revocable references (or membranes) that inform the GC their target is no longer live. This is a place that I'm quite comfortable with WRT to the spec. It means that [[Invoke]] would go away and issues like the ones Jason are concerned about would also just go away. There can still be semantic irregularities introduce by poorly designed proxy handlers. The answer to that seems to be don't do it. Proxies work well for a few specific use cases such as complete membranes. They don't work well for other use cases such as care takers over built-ins with private state. We tried to tweak the Proxy design to make it useable for a wider variety of use cases, but more issues keep turning up. So, it sounds to me that [[Invoke]] needs to go away. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Invoke]] and implicit method calls, once more
On 10/18/2013 11:01 AM, Allen Wirfs-Brock wrote: What your question does help me be more decisive on: We should not be in a rush to add an Invoke, InvokeFunction, or any new traps not needed for membranes, and not subject to a long history of examination. Invoke at least, as a derived trap, can always be added later, after ES6. Isn't there observably different behavior different depending on whether invoke exists or not? Even if you don't implement it in your handler? If that's the case, then it's not guaranteed that it can be added later down the line. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [[Invoke]] and implicit method calls, once more
On Fri, Oct 18, 2013 at 8:06 PM, Brandon Benvie bben...@mozilla.com wrote: On 10/18/2013 11:01 AM, Allen Wirfs-Brock wrote: What your question does help me be more decisive on: We should not be in a rush to add an Invoke, InvokeFunction, or any new traps not needed for membranes, and not subject to a long history of examination. Invoke at least, as a derived trap, can always be added later, after ES6. Isn't there observably different behavior different depending on whether invoke exists or not? Even if you don't implement it in your handler? If that's the case, then it's not guaranteed that it can be added later down the line. I share this concern. Last time we discussed it, Brendan said that we could implement it by falling back to .get if .invoke isn't defined[1]. I'm not sure how well that fits into the rest of the Proxy design, though. [1]: https://mail.mozilla.org/pipermail/es-discuss/2013-September/033610.html ___ 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: [[Invoke]] and implicit method calls, once more
On Oct 18, 2013, at 11:06 AM, Brandon Benvie wrote: On 10/18/2013 11:01 AM, Allen Wirfs-Brock wrote: What your question does help me be more decisive on: We should not be in a rush to add an Invoke, InvokeFunction, or any new traps not needed for membranes, and not subject to a long history of examination. Invoke at least, as a derived trap, can always be added later, after ES6. Isn't there observably different behavior different depending on whether invoke exists or not? Even if you don't implement it in your handler? If that's the case, then it's not guaranteed that it can be added later down the line. Yes, and those differences are not easily fixable in the context of the current Proxy design. As currently defined, some possible uses of Proxies will be broken regardless of whether or not [[Invoke]] is there. Yet, the only reason to add [[Invoke]] at this time would be to try to fix issues with Proxies but even with [[Invoke]] we still have issues. And. for ES6, we're run of time for experimenting with fixes. However, as Mark pointed out, experts can make them work for specific use cases and they are essential for supporting membranes. So we can live with the exiting design (without [[Invoke]]) as an expert feature for building membranes and similar use cases. If we ever come up with a better design (perhaps including [[Invoke]]) we can always introduce a new kind of proxy that works with it. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Inconsistent evaluation order in destructuring assignments
In ES5 all assignments are evaluated following this formula: get a reference via evaluating LHSget a value through evaluating RHSassign the value to the reference However in the current draft, destructuring assignment are evaluated in another order which is (as seen in section 12.13.3) get a value via evaluating RHSparse LHS patternbring parts of RHS into the LHS subpatterns this causes an inconsistency that in expression `[f().x] = [g()]`, g is called BEFORE f. That is weird, and differ from `f().x = g()` where g is called after f. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inconsistent evaluation order in destructuring assignments
Yes, this is intentional and goes all the way back to ES4's original
destructuring proposal, based on array-pattern destructuring implemented
in Opera's Futhark engine. See
http://wiki.ecmascript.org/doku.php?id=discussion:destructuring_assignment#contrast_to_normal_assignment
We want destructuring to be simple: to desugar from let {x, y} = pt; to
let x = pt.x, y = pt.y (but with pt evaluated once only, of course).
/be
BelleveInvis mailto:be5in...@outlook.com
October 18, 2013 12:24 PM
In ES5 all assignments are evaluated following this formula:
1. get a reference via evaluating LHS
2. get a value through evaluating RHS
3. assign the value to the reference
However in the current draft, destructuring assignment are evaluated
in another order which is (as seen in section 12.13.3)
1. get a value via evaluating RHS
2. parse LHS pattern
3. bring parts of RHS into the LHS subpatterns
this causes an inconsistency that in expression `[f().x] = [g()]`, g
is called BEFORE f. That is weird, and differ from `f().x = g()` where
g is called after f.
___
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: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Fri, Oct 18, 2013 at 12:03 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: for (var x of ) print(x.charCodeAt(0)) invokes print() twice in Gecko. No that's not correct, the @@iterator method of String.prototype is supposed to returns an interator the iterates code points and returns single codepoint strings. Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=928508 -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: has the syntax for proxies been finalized ?
On Friday, October 18, 2013, Angus Croll wrote:
thanks André that works!
(I was going by
https://github.com/tvcutsem/harmony-reflect/blob/master/doc/traps.mdwhich
says 'delete')
Cc Tom Van Cutsem to make sure he sees this.
Rick
@angustweets
On Fri, Oct 18, 2013 at 9:38 AM, André Bargull
andre.barg...@udo.edujavascript:_e({}, 'cvml', 'andre.barg...@udo.edu');
wrote:
Follow up question for Tom et al...
Using require('harmony-reflect')
var t = {a:3, c:4};
var p = Proxy(
t,
{
get: function() {},
delete: function(t,x) {
console.log('deleting');
delete t.a;
}
}
);
delete p.c
p; //{a:3}
t; //{a:3}
the console.log is not called and deleting is not trapped.
Am I doing something wrong?
The trap name for the `delete` operator is deleteProperty instead of
delete...
@angustweets
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inconsistent evaluation order in destructuring assignments
On Oct 18, 2013, at 12:24 PM, BelleveInvis wrote:
...this causes an inconsistency that in expression `[f().x] = [g()]`, g is
called BEFORE f. That is weird, and differ from `f().x = g()` where g is
called after f.
but consider
[f().x, h().y] = g(); //assume g() evaluates to an array-like object (and
intentionally removed the RHS array literal)
even if evaluation of the RHS was delayed until after evaluating the first LHS
element, g() would still be evaluated before h(). You might consider
evaluating all of the LHS elements to References before evaluating the RHS.
That could require accumulating an arbitrary large number of pending References
and it wouldn't work for object destructurings. For example:
{x: f().x=_={throw no x}(), h().y} = getPoint();
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
fair enough, that was my point about
except for RAM and CPU, life is going to be easier for devs
so my counter-question would be: is there any way to do that in core so
that we can “”.split() it so that we can have an ArrayLike that with
[1] gives back the single “” and not the whole thing ?
Or does Mathyas have already a RegExp able to split like that with
reasonable perfomance ?
P.S. I am in Chrome and Safari and I had no idea until I've seen that on
twitter what kind of “” we were talking about :D
On Fri, Oct 18, 2013 at 10:34 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Oct 18, 2013, at 10:18 AM, Andrea Giammarchi wrote:
if this is true then .at(symbolIndex) should be a no-brain ?
```
var virtualLength = 0;
for (var x of ) {
virtualLength++;
}
// equivalent of
for(var i = 0; i virtualLength; i++) {
.at(i);
}
```
Am I missing something ?
Yes, we don't want to introduce code point based direct indexing, which
alway requires scanning from the front of the string. We already made that
decision in the context of charPointAt which only use code unit indices.
Allen
On Fri, Oct 18, 2013 at 10:03 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Oct 18, 2013, at 9:05 AM, Anne van Kesteren wrote:
On Fri, Oct 18, 2013 at 4:58 PM, Mathias Bynens math...@qiwi.be
wrote:
On 18 Oct 2013, at 10:48, Anne van Kesteren ann...@annevk.nl wrote:
When you phrase it like that, I see another problem with
codePointAt(). You can't just replace existing usage of charCodeAt()
with codePointAt() as that would fail for input with paired
surrogates. E.g. a simple loop over a string that prints code points
would print both the code point and the trail surrogate code point for
a surrogate pair.
I disagree. In those situations you should just iterate over the
string using `for…of`.
That seems to iterate over code units as far as I can tell.
for (var x of )
print(x.charCodeAt(0))
invokes print() twice in Gecko.
No that's not correct, the @@iterator method of String.prototype is
supposed to returns an interator the iterates code points and returns
single codepoint strings.
The spec. for this will be in the next draft that I release.
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: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On 18 Oct 2013, at 11:05, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Oct 18, 2013 at 4:58 PM, Mathias Bynens math...@qiwi.be wrote: I disagree. In those situations you should just iterate over the string using `for…of`. That seems to iterate over code units as far as I can tell. for (var x of ) print(x.charCodeAt(0)) invokes print() twice in Gecko. Woah, that doesn’t seem very useful. Is that a bug, or the way it’s supposed to work? I thought it was supposed to only iterate over whole code points (i.e. only print once for each code point, not once for each surrogate half). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Oct 18, 2013, at 1:12 PM, Andrea Giammarchi wrote: fair enough, that was my point about except for RAM and CPU, life is going to be easier for devs so my counter-question would be: is there any way to do that in core so that we can “”.split() it so that we can have an ArrayLike that with [1] gives back the single “” and not the whole thing ? Array.from( '팆팆팆'))[1] Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
Please ignore my previous email; it has been answered already. (It was a draft
I wrote up this morning before I lost my internet connection.)
On 18 Oct 2013, at 11:57, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Given that we have charAt, charCodeAt and codePointAt, I think the most
appropiate name for such a method would be 'at':
'팆'.at(0)
Love it!
The issue when this sort of method has been discussed in the past has been
what to do when you index at a trailing surrogate possition:
'팆'.at(1)
do you still get '팆' or do you get the equivalent of
String.fromCharCode('팆'[1]) ?
In my proposal it would return the equivalent of `String.fromCharCode('팆'[1])`.
I think that’s the most sane behavior in that case. This also mimics the way
`String.codePointAt` works in such a case.
Here’s a prollyfill for `String.prototype.at` based on my earlier proposal:
https://github.com/mathiasbynens/String.prototype.at Tests:
https://github.com/mathiasbynens/String.prototype.at/blob/master/tests/tests.js
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On 18 Oct 2013, at 15:12, Andrea Giammarchi andrea.giammar...@gmail.com wrote: so my counter-question would be: is there any way to do that in core so that we can “”.split() it so that we can have an ArrayLike that with [1] gives back the single “” and not the whole thing ? This brings us back to the earlier discussion of whether something like `String.prototype.codePoints` should be added: http://esdiscuss.org/topic/how-to-count-the-number-of-symbols-in-a-string I think it would be useful ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
If I understand Allen answer looks like `Array.from(“”).length` would do, being 3, and making the operation straight forward? Cheers On Fri, Oct 18, 2013 at 1:33 PM, Mathias Bynens math...@qiwi.be wrote: On 18 Oct 2013, at 15:12, Andrea Giammarchi andrea.giammar...@gmail.com wrote: so my counter-question would be: is there any way to do that in core so that we can “”.split() it so that we can have an ArrayLike that with [1] gives back the single “” and not the whole thing ? This brings us back to the earlier discussion of whether something like `String.prototype.codePoints` should be added: http://esdiscuss.org/topic/how-to-count-the-number-of-symbols-in-a-stringI think it would be useful ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Interesting: A Simple Visual Model for Promises
At http://flippinawesome.org/2013/10/14/a-simple-visual-model-for-promises/. I enjoyed it. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
Given that you can only use the proposed String.prototype.at() properly for
indexes 0 if you know the index of a non-BMP character or lead surrogate
by some other means, or if you will test the return value for a trailing
surrogate, is it really an advantage over using codePointAt / fromCodePoint?
The name at is so tempting I'm imagining naive scripts of the form for (i
= 0; i s.length; ++i) { r += s.at(i); } which will work fine until they
get a non-BMP input at which point they're suddenly duplicating the
trailing surrogates.
Pushing people towards for-of iteration and even Allen's Array.from(
'팆팆팆'))[1] seems safer; users who need more subtle things have have
codePointAt
/ fromCodePoint available and hopefully the knowledge to use them.
On Fri, Oct 18, 2013 at 1:30 PM, Mathias Bynens math...@qiwi.be wrote:
Please ignore my previous email; it has been answered already. (It was a
draft I wrote up this morning before I lost my internet connection.)
On 18 Oct 2013, at 11:57, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Given that we have charAt, charCodeAt and codePointAt, I think the most
appropiate name for such a method would be 'at':
'팆'.at(0)
Love it!
The issue when this sort of method has been discussed in the past has
been what to do when you index at a trailing surrogate possition:
'팆'.at(1)
do you still get '팆' or do you get the equivalent of
String.fromCharCode('팆'[1]) ?
In my proposal it would return the equivalent of
`String.fromCharCode('팆'[1])`. I think that’s the most sane behavior in
that case. This also mimics the way `String.codePointAt` works in such a
case.
Here’s a prollyfill for `String.prototype.at` based on my earlier
proposal: https://github.com/mathiasbynens/String.prototype.at Tests:
https://github.com/mathiasbynens/String.prototype.at/blob/master/tests/tests.js
___
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: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Oct 18, 2013, at 1:29 PM, Allen Wirfs-Brock wrote: Array.from( '팆팆팆'))[1] maybe even better: Uint32Array.from( '팆팆팆'))[1] Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Oct 18, 2013, at 4:01 PM, Allen Wirfs-Brock wrote: On Oct 18, 2013, at 1:29 PM, Allen Wirfs-Brock wrote: Array.from( '팆팆팆'))[1] maybe even better: Uint32Array.from( '팆팆팆'))[1] err...maybe not if you want a string value: String.fromCodePoint(Uint32Array.from( '팆팆팆')[1]) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On Oct 18, 2013, at 4:01 PM, Allen Wirfs-Brock wrote:
/
// On Oct 18, 2013, at 1:29 PM, Allen Wirfs-Brock wrote:
//
// Array.from( '???'))[1]
//
// maybe even better:
//
// Uint32Array.from( '???'))[1]
/
err...maybe not if you want a string value:
String.fromCodePoint(Uint32Array.from( '???')[1])
That does not seem to be too useful:
js String.fromCodePoint(Uint32Array.from(\u{1d306}\u{1d306}\u{1d306})[1])
\u
According to
http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/index.html#String,
String.prototype[@@iterator] does not return plain code points, but the
String value for the code point.
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On 18 Oct 2013, at 17:51, Joshua Bell jsb...@google.com wrote:
Given that you can only use the proposed String.prototype.at() properly for
indexes 0 if you know the index of a non-BMP character or lead surrogate by
some other means, or if you will test the return value for a trailing
surrogate, is it really an advantage over using codePointAt / fromCodePoint?
The name at is so tempting I'm imagining naive scripts of the form for (i =
0; i s.length; ++i) { r += s.at(i); } which will work fine until they get a
non-BMP input at which point they're suddenly duplicating the trailing
surrogates.
Pushing people towards for-of iteration and even Allen's Array.from(
'팆팆팆'))[1] seems safer; users who need more subtle things have have
codePointAt / fromCodePoint available and hopefully the knowledge to use them.
Just because new features can be used incorrectly doesn’t mean the feature
isn’t useful. `for…of` on strings and `String.prototype.at` are two very
different things for two very different use cases. It’s a matter of using the
right tool for the job, IMHO.
In your example (iterating over all code points in a string), `for…of` should
be used.
`String.prototype.codePointAt` or `String.prototype.at` come in handy in case
you only need to get the first code point or symbol in a string, for example.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On 19 Oct 2013, at 01:12, Mathias Bynens math...@qiwi.be wrote: `String.prototype.codePointAt` or `String.prototype.at` come in handy in case you only need to get the first code point or symbol in a string, for example. Are they useful for anything else, though? For example, if I wanted to get the second symbol in a string, how would I do that? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
