Add missing ES2015 String built-ins

[svaarala]

• [x] String.fromCodePoint() - #1049
• [x] String.prototype.codePointAt() - #1043
• [x] String.prototype.endsWith() - #1324
• [x] String.prototype.includes() - #1326
• [x] String.prototype.repeat() - #1050
• [x] String.prototype.startsWith() - #1324
• [ ] String.prototype.normalize() - requires more Unicode tables or external Unicode library
• [ ] String.raw() - related to template support
• [ ] String.prototype[@@iterator]
• [ ] String iterator support
• [ ] String.prototype.fromCharCode() non-BMP behavior; keep default (non-standard) behavior?

[fatcerberus]

Iterators require for...of support correct?

[svaarala]

It's actually the other way around: for-of requires iterators but you can also use iterators directly, e.g.:

> var str = 'foo\u{1f4a9}bar'; var it = str[Symbol.iterator]();
undefined
> console.log(it.next());
{ value: 'f', done: false }
undefined
> console.log(it.next());
{ value: 'o', done: false }
undefined
> console.log(it.next());
{ value: 'o', done: false }
undefined
> console.log(it.next());
{ value: '💩', done: false }
undefined
> console.log(it.next());
{ value: 'b', done: false }
undefined
> console.log(it.next());
{ value: 'a', done: false }
undefined
> console.log(it.next());
{ value: 'r', done: false }
undefined
> console.log(it.next());
{ value: undefined, done: true }

It would also be possible (and probably quite sensible) to implement fast paths like iterating a plain string without creating an actual iterator object.

[svaarala]

In general iterators will need some prototyping to find a well working, minimal solution. Duktape actually already implements iteration using an iterator state object to ensure key stability during iteration. So ideally that approach could be generalized so that there wouldn't multiple solutions used in parallel.

But because it's not a trivial change it'll require a few prototypes and iteration to find out what would work well. Until then I'm steering clear of iterator support :)

[fatcerberus]

That's kind of annoying that you have to call .next() one final time to get the "done" notice. But I guess since an iterator is conceptually a stream you can't actually know (in the general case) if you've reached the end until you try to read past it.

[svaarala]

Opened #1047 for iterator discussion.

[fatcerberus]

I guess .startsWith() and .endsWith() can only be done with a regular expression now. Odd, for some reason I thought ES5 had those.

[svaarala]

Many of these can be filled in easily using polyfills. The interesting ones are IMO:

• .normalize(): this is a rather heavy Unicode dependency which will most likely require some rethinking of the Unicode tooling (which is already creaking a bit for e.g. case insensitive regexps)
• .repeat(): this would often be very useful and implementing it natively would be good because it can be much, much more efficient than a polyfill
• The iterator stuff

[svaarala]

There are pulls for String.prototype.codePointAt(), String.fromCodePoint(), and String.prototype.repeat(). These are the bindings I'd most like to get into master first and I probably won't try to implement any more for 2.0 release (I'll work on Symbols and Node.js Buffer gap instead).

[fatcerberus]

Symbols

Yay! 😀 It'll be good to have Symbol support for Duktape 2.0, I already have some use cases lined up for them :)

String.fromCodePoint() and String.codePointAt() are definitely welcome though, especially in light of TextDecoder and \u{H+} Unicode escapes.

[svaarala]

Re: the codepoint functions: that's why I'd like to get them into master so that the non-BMP features would be mostly complete (not 100% because there's RegExp unicode mode etc, but still).

String.prototype.repeat() is great for testcases for example :-)

[denisdemaisbr]

I don't know if this thread is the best local to ask, but, Duktape have a seralize functions like php ] ?

[svaarala]

@denisdemaisbr There is http://duktape.org/api.html#duk_dump_function and http://duktape.org/api.html#duk_load_function but that's the extent of current proper serialization support. Plain structured values can be mostly serialized and deserialized using the custom JX format, but that doesn't preserve inheritance etc, and doesn't handle functions.

[denisdemaisbr]

@svaarala thanks for reply!

[svaarala]

Once startsWith(), endsWith(), and includes() are complete, the straightforward cases should be done. The remaining bindings need some ground work, e.g. symbol/iterator support, template strings, etc.