All right. I'm not 100% convinced, but either way I think we need to understand better how to remove these features' side-effects from JavaScript when disabled. Mads (or anyone else) can you provide any thoughts on how we can implement the following in our bindings generator? (1) We need to be able to disable the JavaScript constructor easily. (2) We need to be able to say "C++ NULLs --> JavaScript undefineds". I believe this is fairly easy? (3) We need to be able to manipulate at run-time whether a property should be enumerated. We'd need to do this on at least Window. I assume there are others.
On Mon, Sep 21, 2009 at 4:37 PM, Darin Fisher <da...@chromium.org> wrote: > I agree. Our practice of releasing experimental features default disabled > behinda command line flag is extremely valuable. We should make sure that > this works > well for new web APIs. It will continue to be a valuable tool down the > road. > > It is important that we have features available in stable, beta, and dev > channels > this way. Otherwise, what we ship to stable is not the same build > configuration > as what we ship to beta, and that can cause even more problems. > > -Darin > On Mon, Sep 21, 2009 at 4:23 PM, John Abd-El-Malek <j...@chromium.org> wrote: > On Mon, Sep 21, 2009 at 3:59 PM, Jeremy Orlow <jor...@chromium.org> wrote: > >> On Mon, Sep 21, 2009 at 3:51 PM, John Abd-El-Malek <j...@chromium.org> >> wrote: >>> >>> On Mon, Sep 21, 2009 at 3:43 PM, Jeremy Orlow <jor...@chromium.org> >>> wrote: >>> >> Please reply to >>>> https://lists.webkit.org/pipermail/webkit-dev/2009-September/009995.html >>>> then. >>>> >>> >>> What's wrong with this thread? We're discussing what to do in Chrome. >>> >> >> What we do in Chrome affects WebKit in terms of performance >> and maintenance. This is why the thread existed to begin with. Any >> decision that we make that affects the rest of the ports should be discussed >> there unless it's obviously the right thing to do for them. (Which this >> isn't.) >> > > Chrome has very different requirements than other products that use WebKit. > Our dev/beta/stable channel approach means we can move fast, but more > differences between these builds pushes us the other direction. > This is mostly just a PSA: If we can find ways to solve these problems 100% transparently to everyone else, then sure. But if not, then we need to discuss it on WebKit-dev. Adding run-time flags does affect others, which is why that WebKit-dev thread was started. I guess adding custom functions to the v8 bindings doesn't affect others much (since we're the only port using v8), but I want to be sure that we're conscious of when our decisions have an impact on the rest of the WebKit community and that we bring things up on WebKit-dev when it does. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
