I think we should plan for success a bit more than in the past. The CSS vendor prefixes were supposed to be short-term, but some have persisted without de-jure standardization, IIRC, for years. That's the downside we can avoid cleanly by naming per draft spec.
Also, we are not decided yet that we will ship Firefox 4 with Proxy defined, but we are trying it in betas precisely to see how it works in the field (and to get usability and other developer feedback). As with any experimental or non-standard feature, we reserve the ability to make breaking changes in the interest of standardization, down the road. This "caveat developer" doesn't always work, of course: wild success may mean we're stuck with something not standardizable (__proto__, ahem). But that outcome provides useful signals for TC39 or whoever is tending to the evolution of the standardized language, even if the too-popular non-standard extension is a mixed bag. Design by committee is a mixed bag too :-/. Simple modules may offer a better way, so we don't have to repeat this stunt: instead of binding Proxy in the global object, we provide a "@harmony:proxies" or some such "anti-URL" that is a valid MRL, loadable without delay by a module declaration: <script type="harmony"> // place-holder mime type module proxies = load "@harmony:proxies"; import proxies.Proxy; </script> This moves the name reserving/colliding problem from the window object to the anti-URL, @-prefixed built-in part of the MRL space, but that's a green field and we can (try to) prescribe how it can be developed by implementors. /be On Jul 2, 2010, at 9:23 AM, Allen Wirfs-Brock wrote: > I just noticed from John Resig’s Twitter stream that Proxies are now in the > FF nightlies. I think this sort of implementation experience is exactly > what we need to be doing for features that are proposed for Harmony. > However, this announcement starting me thinking about what happens when > inevitably there are differences between this early experimental > implementation and the final ES-Harmony specification. How can we encourage > such implementation and usage without also risking premature de facto > standardization of details that ultimately may need to change? Can we help > JavaScript programmers recognize such experimental features? > > This might be done with a technique similar to CSS’s vender-specific naming > conventions (eg, _moz_Proxy) or via namespacing. In either case, we won’t > necessary need to use vendor names. For example, “TC39exp”, is probably a > pretty collision safe global name so you might have for example TC39exp.Proxy. > > I don’t have any personal experience with CSS vender extensions, but my > expression is that they may be somewhat a mixed bag from an interoperability > perspective. Is this the case? I don’t want to send us down a path that is > a folly but it does seem like it would be wise to clearly tag experiments as > such. > > Thoughts? > > Allen > > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
