Has the C# approach to namespace extension been considered at all? With extension methods (one of the foundational primitives used to implement their LINQ querying system) they address this by making extension namespaces 'opt-in' - extension methods are only 'available' on an object if you've imported the namespace (or module, if you like) that contains the extension methods. And extension methods only live on static classes, so they don't get pulled in by accident if you follow some basic guidelines.
The other thing they do here is (IIRC) an extension method never obscures a member that is already on the object, and they don't show up in reflection - they are not members *of* the object(s) they extend, they're just callable on that object thanks to some compiler machinery. Hypothetically (I haven't given this a ton of thought), how this might apply to JS: The new API extensions for prototypes like Array and String and so on are opt-in, through importing the module that contains them, or perhaps explicitly importing the new API python-style: from __es6__ import newAPIs This is also something you could polyfill given a working module loader implementation. I guess one downside is this introduces another 'use strict' style mode, which is particularly gross. If that's not enough, you find a way to introduce the resolution behavior I described from C#, where the properties aren't enumerable on the objects they're attached to (so no 'in', etc), they can be overwritten, and they never shadow existing values. Sadly there isn't a direct analogue here, since C# implements this behavior at compile time - the 'method invocations' get mapped to static method calls by the compiler. A downside to this would be that it makes it impossible to tell whether the builtins are available to call - I don't know how you'd fix that. Maybe expose the information in places existing code doesn't look, like make getOwnPropertyDescriptor still return the property, just with the relevant non-visibility properties set. On 20 October 2014 00:55, Andy Wingo <wi...@igalia.com> wrote: > On Sun 19 Oct 2014 02:46, Fabrício Matté <ultco...@gmail.com> writes: > >> But in reality, many developers simply won't follow the best practices, >> and as Domenic said, browser vendors don't want to ship changes that >> break existing code. >> >> Looks like we have reached a stalemate, and I believe this is something >> that should be addressed before ES6 is officially publicized. > > There is no way it can be addressed in general -- we want to be able to > define new names on prototypes, but this desire is always limited by > "web reality". All we can do is instrument, measure, guess, try, and, > in sad cases like this one, admit defeat if some names just don't work. > > Andy > _______________________________________________ > 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
