Whether or not new ES6 built-ins are visible as global object properties isn't the key point of this proposal. I suggest that they should not, but the core of the proposal certainly allows for that possibility. I just want to make sure that we don't get hung up on debating that point while ignoring the details of the "Basic Approach" I proposed.
On May 6, 2012, at 9:18 AM, David Bruant wrote: > Le 04/05/2012 18:37, Allen Wirfs-Brock a écrit : >> >> >> "typeof builtinGlobalName" doesn't change in anything I proposing here. > I understand, but "'WeakMap' in this" or "'WeakMap' in window" is > something people will use. That's a way of doing feature detection as well. Ultimately, people will feature detect new features in whatever way they are detectable. I agree that it is worthwhile look deeper at feature detection implications of these proposals but I don't think that "all old forms of feature detection apply to new features" is necessarily a requirement. > >> From the perspective of ES code and identifier resolution there is >> simply a single global lexical contour that includes all built-ins, >> top-level declarations, and properties of the global object. The >> "sub-environments" I'm talking about is simply a means to define the >> interactions between language induced bindings and properties of the >> global object (if there is one). It isn't at all clear to me why >> WeakMap, Map, or any other future ES global binding should be >> polluting the property name space of the DOM window object. > It isn't to me either why 'Array' pollutes the DOM window object, but > that's how it's been implemented. > it's a precedent, but bad precedents should necessarily be followed. In browsers, Array must be in the DOM window object to maintain compatibility with existing code. That isn't the case for WeakArray. I think as we add new feature we need to balance precedence with other considerations. This proposal also addresses the scoping of global var and let. You could make a similar argument about them: Global declarations (var and function in ES<=5.1) have always been implemented as polluting the windows object. This is a precedent that all global declarations add properties to the windows object, hence for consistency let/const/module/class/import/etc. at the global level must do so. However, in other threads we have discussed plenty of reasons why that isn't desirable . >> Why is referencing window.WeakMap a good idea? > From an absolute standpoint, I don't think it is, we agree on that. But > it would just make new features consistent with old features. For a > newcomer to the language 15 years from now, it will be inconsistent to > realize that for built-ins, some identifier have a global object > property counterpart and some don't. > The only reason that makes a "WeakMap" global object property a "good > idea" is consistency. That's also how it's currently implemented in > Firefox and Chrome. I don't think we should accept experimental implementation of ES6 features in an ES5 browser as binding precedent. If we do, then first to implement gets to make all the design decisions and pretty much marginalized the role of TC39. But the main issue you are bringing up concerns the importance of internal consistency and precedent in evolving ES. I think those are significant factors, but not the only ones. We have to balance them against other considerations including expressibility, robustness, and future friendliness. The key issue here is the role in ES of the global object. In that past, this object has served dual rules. It is both part of the host environment's domain object model and it is the global scoping contour of the ES language. While this may have been a nice, simplifying assumption in the early days of JS, it just doesn't hold up anymore. Some issues with equating the host global object and the ES global scope contour: * ES global declarations modify/pollute part of the host domain object model. * A host independent ES program has no way of knowing what global names can safely declare. * A host has no way of knowing what property names it safely define that won't conflict with ES code. * The host may inadvertently modify ES program global bindings. * The browser isn't the only host environment. T39 has no way to safely assign global names to built-ins. * Object property semantics may be insufficiently to represent current or future ES global binding semantics (see temporal dead zone discussions) * In a strict ES programs, the global object is the only mutable (with-like) scope contour. This prevents static detection of unresolvable variable reference. * The host must provide an extensible global object so new bindings can be added to it. In the browser environment, we must preserve enough of these characteristic to ensure compatibility with existing code. However, It isn't clear why a new host environment that didn't have legacy code compatibility constraints should be burdened with these issues. In many cases, for such new hosts, the best semantics is probably one that does not even have a global object. Such environments potentially include nested Module Loader created environments within the browser. What this proposal is trying to do, is to define the new ES6 global scope semantics in way that accommodates the reality of browser legacy compatibility while not forcing its quirks on new uses of ES. I've tried to do this in a manner that, while not 100% invisible, would make no noticeable difference the vast majority of existing or future ES code. This is what I'm most interested in getting feedback on. > Acknowledging that built-in identifiers are aliased as global object > properties in web browsers, what is the downside of continuing? > The proposals permit browsers to do so, if that is what they want. I don't think they should, but that is a separable issue. The core question is about allowing non-browsers to avoid global object pollution or even to not have a global object. Allen > David > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
