On Wed, Oct 1, 2014 at 7:51 PM, Ehsan Akhgari <[email protected]> wrote:
> On 2014-10-01, 1:20 PM, Till Schneidereit wrote: > >> That's a great point. It would be great if we can adopt >> https://wiki.mozilla.org/WebAPI/ExposureGuidelines for new JS >> fatures as well. >> >> >> Yes, I think we should consider that. The situation is somewhat >> different in that we usually only implement features that are stable, >> specced, and agreed upon by tc39 and thus have buy-in by other vendors. >> ("Usually" because we do some experimental Nightly-only stuff, but that >> is so exotic, really, that FF devs wouldn't begin to think that it's >> production-usable.) >> > > Sure, but I think it would still be valuable, even if it's only used as an > announcement mechanism. > I agree, and will bring it up with other SpiderMonkey devs. > > Also, out of curiosity, do we have ways of hiding JS built-ins >> behind prefs similar to DOM APIs? >> >> >> Not really: by the time the prefs are read, we have already created >> globals, so those either have the builtins (if we default to installing >> them) or won't ever get them, regardless of the pref's value (if we >> default to not installing them). >> > > Hmm.. I'm not sure about the details of the code in question. Is this > easy to solve? At what point exactly during startup do we create those > built-ins? > The full answer to that is actually ridiculously complicated. The part relevant here is, though: very early on in at least some cases. Too early to rely on preferences, if I'm not mistaken. I think the only reliable way would be to do it when creating the runtime. > > Also, I think there is great value in having these features available >> without a pref. Chrome uses prefs, and I think is substantially >> diminishes the value for testing things out. Array.prototype.contains is >> a good example for that: if it had been behind a pref, who knows when >> we'd have discovered the web breakage? >> > > I was not suggesting that we should have landed Array.prototype.contains > behind a pref. However, there are other uses for being able to hide things > behind a pref. One great example is this pattern: > > #ifdef NIGHTLY_BUILD > pref("what.ever", true); > #else > pref("what.ever", false); > #endif > > This basically ensures that we don't accidentally end up letting the > feature slip past Nightly before we're "ready" (part of the definition of > ready might be, knowing that the feature is Web compatible, etc.) > Inside SpiderMonkey, we ensure that by doing the Nightly check where the feature is compiled/installed in the first place. For Array.prototype.contains, that is here: http://mxr.mozilla.org/mozilla-central/source/js/src/jsarray.cpp?rev=020a62efb303#3027 Now that obviously doesn't allow you to manually enable these features on Aurora and above. Assuming that you'd want to be able to do that in a fine-grained way, the prefs thing would be even more complicated: we'd have to add a way for the JS engine to query prefs, because just passing in all of them from the outside becomes untenable. One thing that would be possible, I suppose, is to have a single flag "enable experimental extensions", as Chrome does. We should at least consider doing that, without changing our current behavior of having these features enabled by default on Nightly. _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
