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. foo = obj.includes, obj.includes() and String.prototype.includes = foo are enough. 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.
