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.
Post by Andy WingoPost by FabrÃcio Matté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 at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss