On 15 February 2014 21:06, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Feb 15, 2014, at 11:47 AM, Brendan Eich wrote:
C. Scott Ananian wrote:
On Feb 15, 2014 9:13 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Aside: ECMASpeak is neither accurate (we don't
Andreas Rossberg wrote:
On 15 February 2014 20:47, Brendan Eichbren...@mozilla.com wrote:
Using -Speak as a stem conjures Orwell. Not good.
Ah, relax. Gilad Bracha even named his own language Newspeak.
Yeah, but no ECMA -- the double-whammy.
Self-mockery is good.
I pay my dues (see
Are recordings available?
--scott
On Feb 17, 2014 10:26 AM, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
On 15 February 2014 20:47, Brendan Eichbren...@mozilla.com wrote:
Using -Speak as a stem conjures Orwell. Not good.
Ah, relax. Gilad Bracha even named his own
C. Scott Ananian wrote:
Are recordings available?
http://www.infoq.com/presentations/State-JavaScript starting at 1:50
Youtube has more.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Aside: ECMASpeak is neither accurate (we don't work for Ecma, it's JS
not ES :-P), nor euphonious. But here's a pointer:
C. Scott Ananian wrote:
new string object.
new string primitive, because string object (especially with new
in front) suggests new String('hi').
/be
On 14 Feb 2014, at 19:59, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It's a really high bar to get over that closed gate. Unless the exclusion of
a feature was a mistake […] I don't think we should be talking about adding
it to ES6.
It does feel like a mistake to me to introduce
On Feb 15, 2014 9:13 AM, Brendan Eich bren...@mozilla.com wrote:
Aside: ECMASpeak is neither accurate (we don't work for Ecma, it's JS
not ES :-P), nor euphonious.
I'm learning all sorts of things! I guess there are two names here; what's
your preferred phrase for the language used to write
Allen mentioned that `String#at` might not make it to ES6 because nobody in
TC39 is championing it. I’ve now asked Rick if he would be the champion for
this, and he agreed. (Thanks again!)
Looking over the ‘TC39 progress’ document at
: `String.prototype.symbolAt()` (improved
`String.prototype.charAt()`)
Allen mentioned that `String#at` might not make it to ES6 because nobody in
TC39 is championing it. I've now asked Rick if he would be the champion for
this, and he agreed. (Thanks again!)
Looking over the 'TC39 progress
Note that `Array.from(str)` and `str[Symbol.iterator]` overlap
significantly. In particular, it's somewhat awkward to iterate over
code points using `String#symbolAt`; it's much easier to use
`substr()` and then use the StringIterator.
--scott
ps. I see that Domenic has said something similar.
On 14 Feb 2014, at 11:11, Domenic Denicola dome...@domenicdenicola.com wrote:
This was the method that was only useful if you pass `0` to it?
I’ll just avoid the infinite loop here by pointing to earlier posts in this
thread where this was discussed before:
On 14 Feb 2014, at 11:14, C. Scott Ananian ecmascr...@cscott.net wrote:
Note that `Array.from(str)` and `str[Symbol.iterator]` overlap
significantly. In particular, it's somewhat awkward to iterate over
code points using `String#symbolAt`; it's much easier to use
`substr()` and then use the
Yes, I know what `String#at` is supposed to do.
I was pointing out that `String#at` makes it easy to do the wrong
thing. If you do `Array.from(str)` then you suddenly have a complete
random-access data structure where you can find out the number of code
points in the String, iterate it in
To: Mathias Bynens
Cc: es-discuss@mozilla.org list
Subject: Re: `String.prototype.symbolAt()` (improved
`String.prototype.charAt()`)
Yes, I know what `String#at` is supposed to do.
I was pointing out that `String#at` makes it easy to do the wrong thing. If
you do `Array.from(str)` then you suddenly
On Fri, Feb 14, 2014 at 1:34 AM, Mathias Bynens math...@qiwi.be wrote:
Allen mentioned that `String#at` might not make it to ES6 because nobody
in TC39 is championing it. I've now asked Rick if he would be the champion
for this, and he agreed. (Thanks again!)
Published to wiki here:
On Feb 14, 2014, at 1:34 AM, Mathias Bynens wrote:
Allen mentioned that `String#at` might not make it to ES6 because nobody in
TC39 is championing it. I’ve now asked Rick if he would be the champion for
this, and he agreed. (Thanks again!)
Looking over the ‘TC39 progress’ document at
On Fri, Feb 14, 2014 at 10:59 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Feb 14, 2014, at 1:34 AM, Mathias Bynens wrote:
Allen mentioned that `String#at` might not make it to ES6 because nobody
in TC39 is championing it. I've now asked Rick if he would be the champion
for this,
I'm excited to start working on es7-shim once we get to that point!
(String.prototype.at has a particularly simple shim, thankfully...)
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Fri, Feb 14, 2014 at 12:23 PM, C. Scott Ananian ecmascr...@cscott.netwrote:
I'm excited to start working on es7-shim once we get to that point!
(String.prototype.at has a particularly simple shim, thankfully...)
Have you seen: https://github.com/mathiasbynens/String.prototype.at ?
Rick
yes, of course. es6-shim is a large-ish collection of such.
However, it would be much better to use an implementation of
`String#at` which used substr and thus avoided creating and appending
a new string object.
--scott
___
es-discuss mailing list
On 19 Oct 2013, at 12:54, Domenic Denicola dome...@domenicdenicola.com wrote:
My proposed cowpaths:
```js
Object.mixin(String.prototype, {
realCharacterAt(i) {
let index = 0;
for (var c of this) {
if (index++ === i) {
return c;
}
}
}
get realLength() {
so it's a for/of with a break when it finds a code point? if that's the
only use case I'd like to have an example of how convenient it is. I am
just wondering, not saying is not useful (trying to understand
when/where/why I'd like to use .at())
Thanks
On Fri, Oct 18, 2013 at 10:12 PM, Mathias
On Oct 18, 2013, at 10:53 PM, Domenic Denicola wrote:
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
On Oct 18, 2013, at 4:22 PM, André Bargull wrote:
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
* Allen Wirfs-Brock wrote:
The utility of a hypothetical 'at' method is presumably exactly that of
'codePointAt'.
str.at(p)
would just be a convenience for expressing
String.fromCodePoint(str.codePointAt(p))
So the real question is probably, how common is that use case.
Certainly not
On 19 Oct 2013, at 12:15, Bjoern Hoehrmann derhoe...@gmx.net wrote:
Certainly not common enough to warrant a two-character method on the
native string type. Odds are people will use it incorrectly in an
attempt to make their code look concise […]
Are you saying that changing the name to
On 19 Oct 2013, at 00:53, Domenic Denicola dome...@domenicdenicola.com wrote:
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
From: Mathias Bynens [mailto:math...@qiwi.be]
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 It
could be a getter or a generator… Or does
AFAIK that's also what Allen said didn't want to implement in core. An
expensive operation per each invocation due stateless loop over arbitrary
indexes.
Although, strings are immutable in JS so I'd implement that logic creating
a snapshot once and use that as if it was an Array ... something
example mroe readable and with some typo fixed in github:
https://gist.github.com/WebReflection/7059536
license wtfpl v2 http://www.wtfpl.net/txt/copying/
Cheers
On Sat, Oct 19, 2013 at 11:18 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
AFAIK that's also what Allen said didn't
* Mathias Bynens wrote:
On 19 Oct 2013, at 12:15, Bjoern Hoehrmann derhoe...@gmx.net wrote:
Certainly not common enough to warrant a two-character method on the
native string type. Odds are people will use it incorrectly in an
attempt to make their code look concise […]
Are you saying that
Allen Wirfs-Brock wrote:
The use case that we don't support well is any sort of back wards iteration of
the characters of a string. We don't current have an iterator specified to do
it, nor do we have a one stop way to test whether we at looking at the trailing
surrogate of a surrogate pair.
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`
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?
--
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
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.
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
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
___
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
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
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
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
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
/ 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
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`.
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
+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
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)
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
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
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
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
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.
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
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
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
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
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 /
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
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])
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:
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
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
63 matches
Mail list logo