[FYI +blink-dev]
ES6 extends String.prototype with several methods: repeat, startsWith,
endsWith, includes, codePointAt) and adds String.fromCodePoint method.
Firefox ships codePointAt and fromCodePoint since release 29 [1],
startsWith and endsWith since release 17 [2], and repeat since release
LGTM. Worth pointing out that there is also String.raw, which we
intend to ship separately (along with the template string feature,
which it is closely tied to).
/Andreas
On 27 November 2014 at 09:27, Dmitry Lomov dslo...@chromium.org wrote:
[FYI +blink-dev]
ES6 extends String.prototype with
Resending to v8-users since apparently I didn't have permission to post
previously.
On Thu, Nov 27, 2014 at 10:13 AM, Drew Wilson atwil...@chromium.org wrote:
What impact do we expect on web compatibility from apps that may already
be adding attributes named include, etc to their String
It parses module syntax as of the modules proposal in 2012. After
that, the proposal underwent some radical changes, and hadn't really
stabilised until recently, which is why we suspended working on the
implementation. Most of the existing parts are obsolete at this point.
/Andreas
On 27
On Thu, Nov 27, 2014 at 10:13 AM, Drew Wilson atwil...@chromium.org wrote:
What impact do we expect on web compatibility from apps that may already
be adding attributes named include, etc to their String objects?
I think that adding attributes that Firefox is already shipping should be
On Thu, Nov 27, 2014 at 10:35 AM, Dmitry Lomov dslo...@chromium.org wrote:
On Thu, Nov 27, 2014 at 10:13 AM, Drew Wilson atwil...@chromium.org
wrote:
What impact do we expect on web compatibility from apps that may already
be adding attributes named include, etc to their String objects?
Can we add a console log (not a warning) for the canary/dev/beta run
(perhaps stable, too?) for a little while to aid developers with possible
breakages?
If String.prototype.includes is overridden, deleted or accessed (called or
gotten), the log would be printed.
☆*PhistucK*
On Thu, Nov 27,
Relevant CL: https://codereview.chromium.org/761913002/
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
v8-users group.
To unsubscribe from this group and stop receiving
On Thu, Nov 27, 2014 at 11:01 AM, Drew Wilson atwil...@chromium.org wrote:
On Thu, Nov 27, 2014 at 10:35 AM, Dmitry Lomov dslo...@chromium.org
wrote:
On Thu, Nov 27, 2014 at 10:13 AM, Drew Wilson atwil...@chromium.org
wrote:
What impact do we expect on web compatibility from apps that
On Thu Nov 27 2014 at 11:39:17 AM Dmitry Lomov dslo...@chromium.org wrote:
On Thu, Nov 27, 2014 at 11:01 AM, Drew Wilson atwil...@chromium.org
wrote:
On Thu, Nov 27, 2014 at 10:35 AM, Dmitry Lomov dslo...@chromium.org
wrote:
On Thu, Nov 27, 2014 at 10:13 AM, Drew Wilson
On Thu, Nov 27, 2014 at 11:44 AM, Jochen Eisinger joc...@chromium.org
wrote:
On Thu Nov 27 2014 at 11:39:17 AM Dmitry Lomov dslo...@chromium.org
wrote:
On Thu, Nov 27, 2014 at 11:01 AM, Drew Wilson atwil...@chromium.org
wrote:
On Thu, Nov 27, 2014 at 10:35 AM, Dmitry Lomov
One suggestion that came out of discussions with folks is:
- add an on-by-default flag 'Enable new Javascript features' that could
be turned off at run-time.
Javascript features we ship will be under that flag for 1 stable release.
I'll investigate feasibility of that.
On Thu, Nov 27, 2014 at
On 27 November 2014 at 12:09, Dmitry Lomov dslo...@chromium.org wrote:
One suggestion that came out of discussions with folks is:
- add an on-by-default flag 'Enable new Javascript features' that could be
turned off at run-time.
Javascript features we ship will be under that flag for 1 stable
This is to ease debugging, not to solve every single case. As much as
possible, log it. On a 'best available' case.
☆*PhistucK*
On Thu, Nov 27, 2014 at 1:14 PM, 'Andreas Rossberg' via blink-dev
blink-...@chromium.org wrote:
On 27 November 2014 at 11:39, Dmitry Lomov dslo...@chromium.org
On Thu, Nov 27, 2014 at 12:52 PM, Philip Jägenstedt phil...@opera.com wrote:
It sure sounds like 'contains' would be less likely to cause trouble,
and is also a slightly better name IMHO.
Is Mozilla on board with renaming it? If they're not keen, I think
following their lead with 'contains'
This is very debateable, really. To me, it makes sense (and in my
experience, also exists) that contains makes more sense (as a shortcuts
for return this.indexOf(str) !== -1) than 'includes'.
☆*PhistucK*
On Thu, Nov 27, 2014 at 1:52 PM, Philip Jägenstedt phil...@opera.com
wrote:
On Thu, Nov
On Thu, Nov 27, 2014 at 12:54 PM, Mathias Bynens mathi...@opera.com wrote:
On Thu, Nov 27, 2014 at 12:52 PM, Philip Jägenstedt phil...@opera.com
wrote:
It sure sounds like 'contains' would be less likely to cause trouble,
and is also a slightly better name IMHO.
Is Mozilla on board with
*shortcut
My last message was probably confusing, so continuing it -
By that, I mean that it makes more sense for 'contains' to exists already
on the web, than for 'includes'.
☆*PhistucK*
On Thu, Nov 27, 2014 at 1:55 PM, PhistucK phist...@gmail.com wrote:
This is very debateable, really. To
*exist
'contains' is the obvious choice, 'includes' is not. This is what I mean.
While 'contains' is better named, 'includes' is less risky and therefore
should be chosen.
I am finally done, I think. Sorry for the triple post.
☆*PhistucK*
On Thu, Nov 27, 2014 at 1:57 PM, PhistucK
On Thu, Nov 27, 2014 at 12:37 PM, PhistucK phist...@gmail.com wrote:
This is to ease debugging, not to solve every single case. As much as
possible, log it. On a 'best available' case.
Logging would be prohibitively expensive as well, and lead to too many
false positives.
We will have to log,
Firefox simply got lucky in the case of the referenced bug, because
some web pages serve different code depending on what browser they
encounter.
On 27 November 2014 at 13:14, Mathias Bynens mathi...@opera.com wrote:
On Thu, Nov 27, 2014 at 1:06 PM, Philip Jägenstedt phil...@opera.com wrote:
Then I guess I am also looking to help educate about new platform features.
I understand this use case is much less needed, though.
☆*PhistucK*
On Thu, Nov 27, 2014 at 9:52 PM, Dmitry Lomov dslo...@chromium.org wrote:
On Thu, Nov 27, 2014 at 8:48 PM, PhistucK phist...@gmail.com wrote:
22 matches
Mail list logo