Idea for Strawman: separate the core standard library itself into modules
This was originally a part of the modules design but was cut due to timing. You can find what did exist on the topic here: harmony:modules_standard
- Matthew Robb
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Isiah Meadows
I know this would break a lot of backwards compatibility completely, so this is purely hypothetical, and I expect this to not have a realistic chance anytime soon.
Anything that breaks backward compatibility will not have a chance, realistic or otherwise, ever.
On Mon, Sep 22, 2014 at 9:04 AM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Isiah Meadows
I know this would break a lot of backwards compatibility completely, so this is purely hypothetical, and I expect this to not have a realistic chance anytime soon.
Anything that breaks backward compatibility will not have a chance, realistic or otherwise, ever.
To square this with Matthew's response, the original idea was to also expose the core functionality as modules, to give you the ability to grab "clean" versions of any standard functions you wanted, while the preexisting global versions would still be there.
Tab Atkins Jr. wrote:
OnMon, Sep 22, 2014 at 9:04 AM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Isiah Meadows
I know this would break a lot of backwards compatibility completely, so this is purely hypothetical, and I expect this to not have a realistic chance anytime soon.
Anything that breaks backward compatibility will not have a chance, realistic or otherwise,ever.
To square this with Matthew's response, the original idea was to also expose the core functionality as modules, to give you the ability to grab "clean" versions of any standard functions you wanted, while the preexisting global versions would still be there.
Right!
Isaih, this is good news: you can't insist on removing stuff, but if you put the cleanups and better organization in new clothes, the old drab ones will fade into disuse (even if they don't ever go away).
This is kind of a "law of the Web." It turns out compat does break, and no one notices (much), over very long timeframes. At least, we saw this going from the early Web to the modern days, with a few things (corner cases in JS and CSS table layout). But these were never predictable, or major.
With strict-by-default modules, we can hope for 'with' to whither away over a decade. I wouldn't bet on it, since strict mode is still opt-in and will be for <script>, forever.
Brendan Eich wrote:
'with' to whither away
Rats, my fingers betrayed my punning brain.
We could hope for 'with' to wither away. Or 'whith' to whither away.
Gonna pronounce with using voiced glottal fricative from now on.
@Brendan I'm aware of that pattern. For now, I'm more concerned about the option of modules. It would be nice to import the standard library features you need, and if, for some reason, one of the API natives get overwritten, you have a fallback.
Transitioning the native API to modules is more of a proposed long term goal of this proposal. It'll take years to fully realize.
With libraries like Knockout utilizing 'with', I'm not sure it'll go away anytime soon.
Also, withering works in two directions - we now have 'proto' everywhere.
Is proto deprecated by TC39? The spec says otherwise.
Not deprecated -- any reason you brought it up in the context of 'with'?
Isiah Meadows wrote:
Transitioning the native API to modules is more of a proposed long term goal of this proposal. It'll take years to fully realize.
True, and I don't see a shortcut. Do you?
Having TC39 rush something designed by champions and ratified by committee but without any developers or engine implementors actually chewing on it for months is very risky. We'd regret doing anything like that, you would too.
It makes me want to see github projects cooperating and competing on this challenge. It's not trivial or easy enough that I think a small group should have to get it right in a constrained schedule and testing network.
My point was that I don't believe that putting the standard library in modules would help with people using the current library. Even in 5 years.
I mentioned proto as an example for something that didn't go away although it wasn't supported by a major browser and wasn't specced (to the point it got specced). I don't think 'with' is going anywhere soon either. The "fresh copy" argument sounds good though.
I have used proto simply because it allows for a feature nothing else has: to change the [[Prototype]] of a callable / constructor.
This isn't the same as "with" or other backward-compatibility hacks. It's a feature that I need to fake out some other code that uses "instanceof" and also be callable.
If there's a better way to do this, please let me know.
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20140923/94f65a3c/attachment
Aha. I wasn't aware of Object.setPrototypeOf. That sounds like it will solve my use case. Thanks.
A way to start would add new built-ins only in modules. jjb
Until modules are shipping in engines we will have to continue to add globals.
On Mon, Sep 22, 2014 at 8:17 PM, Erik Arvidsson <erik.arvidsson at gmail.com>
wrote:
Until modules are shipping in engines we will have to continue to add globals.
Honestly, I think an interim solution makes the most sense. Perhaps as simple as a single namespace for adding new standard lib functionality to. Ideally this would be broken down into pseudo-modular objects. This would both be easier to map to modules in the future, polyfill now, and lines up better with existing code management practices.
- Matthew Robb
Benjamin Grurnbaum wrote:
I mentioned proto as an example for something that didn't go away although it wasn't supported by a major browser
This is misworded -- as written it says proto was not supported by any major browser, but I am pretty sure you meant "it wasn't supported by one major browser" -- in particular, IE prior to IE11.
I know this will never happen until at least ES9 (and this is highly optimistic) because of compat issues, but I was thinking: would separating the core standard library into modules be a good idea?
I have a repo containing my idea in a little more detail here ( impinball/harmony-stdlib).
I also have more than one idea as to how it could be, and I'm very open to suggestions and feedback.
I know this would break a lot of backwards compatibility completely, so this is purely hypothetical, and I expect this to not have a realistic chance anytime soon.