Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

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

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

Are recordings available? --scott On Feb 17, 2014 10:26 AM, "Brendan Eich" wrote: > Andreas Rossberg wrote: > >> On 15 February 2014 20:47, Brendan Eich wrote: >> >>> > Using "-Speak" as a stem conjures Orwell. Not good. >>> >> >> Ah, relax. Gilad Bracha even named his own language Newspeak.

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

Andreas Rossberg wrote: On 15 February 2014 20:47, Brendan Eich 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 "wat" played wit

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Feb 17, 2014, at 4:38 AM, Andreas Rossberg wrote: > On 15 February 2014 21:06, Allen Wirfs-Brock wrote: >> ... >> But remember, prior to ES5, it was closer to Cobolish machine language. No >> structured control, goto's targeting numeric step numbers, intermediate >> results referenced by s

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 15 February 2014 20:47, Brendan Eich wrote: > Using "-Speak" as a stem conjures Orwell. Not good. Ah, relax. Gilad Bracha even named his own language Newspeak. Self-mockery is good. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https:/

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 15 February 2014 21:06, Allen Wirfs-Brock 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" >> > wrote: >>> > Aside: "ECMASpeak" is neither accurate (we don't work for Ecma, it's JS

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Feb 15, 2014, at 11:47 AM, Brendan Eich wrote: > C. Scott Ananian wrote: >> >> On Feb 15, 2014 9:13 AM, "Brendan Eich" > > wrote: >> > Aside: "ECMASpeak" is neither accurate (we don't work for Ecma, it's JS >> > not ES :-P), nor euphonious. >> >> I'm learning all

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

C. Scott Ananian wrote: On Feb 15, 2014 9:13 AM, "Brendan Eich" > 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 preferre

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Feb 15, 2014 9:13 AM, "Brendan Eich" 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 algorithms in the

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 14 Feb 2014, at 19:59, Allen Wirfs-Brock 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 `String.prototype.codePoi

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

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 ___

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

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 es-d

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Fri, Feb 14, 2014 at 12:23 PM, C. Scott Ananian wrote: > 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

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

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

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Fri, Feb 14, 2014 at 10:59 AM, Allen Wirfs-Brock wrote: > 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. (Th

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

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

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Fri, 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!) > Published to wiki here: http://wiki.ecmascri

RE: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

ebruary 14, 2014 12:12 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 `Arr

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 have a complete random-access data structure where you can find out the number of code points in the String, iterate it in reverse

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 14 Feb 2014, at 11:14, C. Scott Ananian 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 StringIterator. `

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 14 Feb 2014, at 11:11, Domenic Denicola 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:

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

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.

RE: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

: `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 'TC3

Re: `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’ document at

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 19 Oct 2013, at 12:54, Domenic Denicola 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() { >let counter

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

a nested loop might be a concrete case where `O(n)` happens ... not so common with strings but quite possibly used in many parsers implemented in JS itself. On Sat, Oct 19, 2013 at 12:11 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: > >> The use case that we don't support well is any sort

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

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.

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

* Mathias Bynens wrote: >On 19 Oct 2013, at 12:15, Bjoern Hoehrmann 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 t

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

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

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

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 like

RE: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

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 `f

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 19 Oct 2013, at 00:53, Domenic Denicola wrote: > On 19 Oct 2013, at 01:12, "Mathias Bynens" 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 an

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 19 Oct 2013, at 12:15, Bjoern Hoehrmann 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 something that is lo

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

* 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. Certain

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

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...ma

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Oct 18, 2013, at 10:53 PM, Domenic Denicola wrote: > On 19 Oct 2013, at 01:12, "Mathias Bynens" 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 fo

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

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 By

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 19 Oct 2013, at 01:12, "Mathias Bynens" 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

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 18 Oct 2013, at 17:51, Joshua Bell 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

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(Uint

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])

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()`)

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

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 wrote: > On 18 Oct 2013, at 15:12, Andrea Giammarchi > wrote: > > > so my counter-question would be: is there

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 18 Oct 2013, at 15:12, Andrea Giammarchi 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 di

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 wrote: > Given that we have charAt, charCodeAt and codePointAt, I think the most > appropiate name for such

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 Arra

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 18 Oct 2013, at 11:05, Anne van Kesteren wrote: > On Fri, Oct 18, 2013 at 4:58 PM, Mathias Bynens 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 "💩") > p

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

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Fri, Oct 18, 2013 at 12:03 PM, Allen Wirfs-Brock 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 sing

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

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); > } > > ``` > >

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 wi

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 wrote: >

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'.charCode

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

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 wrote: >> On 18 Oct 2013, at 10:48, Anne van Kesteren wrote: >>> When you phrase it like that, I see another problem with >>> codePointAt(). You can't just replace existing usage of charCodeA

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 wrote: > ES6 fixes `String.fromCharCode` by introducing `String.fromCodePoint`. > > Similarly, `String.prototype.charCodeAt` is fixed by > `String.prototype.codePointAt`. > > Should the

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

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Fri, Oct 18, 2013 at 4:58 PM, Mathias Bynens wrote: > On 18 Oct 2013, at 10:48, Anne van Kesteren 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 p

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Fri, Oct 18, 2013 at 11:53 AM, Mathias Bynens wrote: > On 18 Oct 2013, at 10:25, Rick Waldron 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 cl

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 18 Oct 2013, at 10:48, Anne van Kesteren wrote: > On Fri, Oct 18, 2013 at 1:46 PM, Mathias Bynens 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 re

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 18 Oct 2013, at 10:25, Rick Waldron wrote: > String.prototype.elementAt? This may be confusing too, since the spec refers to `elements` as code units, not code points. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/list

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 18 Oct 2013, at 10:39, Domenic Denicola wrote: > Doesn't Unicode have some name for "visual representation of a code point"? > Maybe it's "symbol"? Not that I know of. I guess “Character” (http://www.unicode.org/glossary/#character) comes close, but we can’t really use that because `String

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Fri, Oct 18, 2013 at 1:46 PM, Mathias Bynens 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

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 11:15 AM, Mathias Bynens 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

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Fri, Oct 18, 2013 at 10:47 AM, Mathias Bynens wrote: > On 18 Oct 2013, at 09:21, Rick Waldron 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 “Graphem

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

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

- Forwarded message -- From: Mathias Bynens To: Rick Waldron Cc: "es-discuss@mozilla.org list" 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 wrote: > I think the i

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On 18 Oct 2013, at 09:21, Rick Waldron 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 agr

Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)

On Fri, Oct 18, 2013 at 8:46 AM, Mathias Bynens 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

`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? >> '𝌆'.