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: > >> Well, you got the wrong idea. >> I am looking to help developers, not to tell them something is >> necessarily wrong. >> The expensive ones (like "includes" in obj) are not part of "best >> available" in my opinion. >> > > These are the ones that cause problems though (both in 'values' case and > in Array.prototype.contains case). > > >> foo = obj.includes, obj.includes() and String.prototype.includes = foo >> are enough. >> > > These typically wouldn't cause problems (as in: won't break web sites) > since all this likely overrides the ones we ship. > > The point is to note that this new, potentially controversial (its name >> only, of course) feature was introduced and that if you suddenly see >> issues, take a note that it was added, in case it applies to your case. If >> not, carry on. >> >> Logs such as these - >> String.prototype.includes was recently added to the platform and was >> overridden by this website. If you expect the standard variation of this >> method, perhaps polyfill it only when it does not exist. >> String.prototype.includes was recently added to the platform and used by >> this website. If you see issues, consider this as a possible culprit. >> >> >> ☆*PhistucK* >> >> On Thu, Nov 27, 2014 at 2:01 PM, Dmitry Lomov <dslo...@chromium.org> >> wrote: >> >>> >>> >>> 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, for example, every time somebody does an >>> "'includes' in obj". >>> >>>> >>>> >>>> ☆*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> >>>>> 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 < >>>>> 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 relatively safe, but I'm very leery about being the first >>>>> browser to add >>>>> >>>> new attributes. What can we do to avoid a repeat of >>>>> http://crbug.com/409858? >>>>> >>>> Do we have any stats for how often these attributes are already >>>>> in use in >>>>> >>>> web pages (tricky, since some apps are legitimately using them >>>>> for polyfill >>>>> >>>> purposes)? >>>>> >>> >>>>> >>> Correct, this is tricky. We do not have stats (and it is unclear >>>>> how to >>>>> >>> get those stats). >>>>> >>> 'contains' was renamed to 'includes' precisely to reduce possible >>>>> web >>>>> >>> compat breakage. >>>>> >>> Unfortunately we will not know of any breakage until we ship this >>>>> - it >>>>> >>> has been available under a flag for some time, but it looks like >>>>> nobody >>>>> >>> tests with 'Experimental Javascript features' enabled. >>>>> >>> Therefore enabling it early on canary in Chrome 41 process is our >>>>> best >>>>> >>> mitigation in this particular case. >>>>> >> >>>>> >> I'm not sure "let's just launch this and see who complains" is an >>>>> >> acceptable path forward given that this specific approach was tried >>>>> last >>>>> >> release with Array.values and blew up in our face. Why do we think >>>>> this time >>>>> >> will be any different? >>>>> >> >>>>> >> Can we perhaps restrict this to canary + dev channel (and maybe the >>>>> first >>>>> >> beta cut), but hold off on shipping to Stable until we find a way to >>>>> >> generate stats? >>>>> > >>>>> > Shipping this now is de facto canary + dev. >>>>> > I do not know of a way to generate stats for this (unfortunately). >>>>> >>>>> What Dmitry said. Of course, if problems are discovered there, then we >>>>> will roll back before the next beta. But if they aren't then we have >>>>> no realistic way of knowing other than shipping it in beta. That's >>>>> what beta is for, after all. >>>>> >>>>> The good news is that after the previous incident we changed our >>>>> roll-out procedure such that unshipping a feature now consists of only >>>>> swapping a macro invocation. >>>>> >>>>> It's also worth noting that we have shipped many other new features >>>>> without any problems. Array.p.values was the only exception so far. >>>>> >>>>> >>>>> On 27 November 2014 at 11:06, PhistucK <phist...@gmail.com> wrote: >>>>> > 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. >>>>> >>>>> Unfortunately, I believe that is infeasible. As Dmitry already noted, >>>>> it is not at all easy to diagnose the situation, even if you were >>>>> willing to accept lots of false positives. JavaScript is far too >>>>> "dynamic" (and generally broken beyond repair when it comes to >>>>> robustness). Moreover, ES6 adds plenty of new methods across the >>>>> board, and we wouldn't want to install a complicated mechanism like >>>>> that for each and every one of them, even though a priori, there is no >>>>> reason to believe that any one of them has less or more potential for >>>>> breakage than A.p.includes has. >>>>> >>>>> /Andreas >>>>> >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to blink-dev+unsubscr...@chromium.org. >>>>> >>>> >>>> -- >>>> -- >>>> 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 emails from it, send >>>> an email to v8-users+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+unsubscr...@chromium.org. >>> >> >> > -- -- 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 emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
