Idea for Strawman: separate the core standard library itself into modules
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 ( https://github.com/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. -- Isiah Meadows ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 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: http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard - Matthew Robb On Mon, Sep 22, 2014 at 7:53 AM, Isiah Meadows impinb...@gmail.com wrote: 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 ( https://github.com/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. -- Isiah Meadows ___ 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
RE: Idea for Strawman: separate the core standard library itself into modules
From: es-discuss [mailto:es-discuss-boun...@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*. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Idea for Strawman: separate the core standard library itself into modules
On Mon, Sep 22, 2014 at 9:04 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss [mailto:es-discuss-boun...@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. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Idea for Strawman: separate the core standard library itself into modules
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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Idea for Strawman: separate the core standard library itself into modules
@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. On Sep 22, 2014 1:18 PM, Brendan Eich bren...@mozilla.org wrote: Tab Atkins Jr. wrote: OnMon, Sep 22, 2014 at 9:04 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss [mailto:es-discuss-boun...@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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Idea for Strawman: separate the core standard library itself into modules
Transitioning the native API to modules is more of a proposed long term goal of this proposal. It'll take years to fully realize. On Sep 22, 2014 3:10 PM, Isiah Meadows impinb...@gmail.com wrote: @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. On Sep 22, 2014 1:18 PM, Brendan Eich bren...@mozilla.org wrote: Tab Atkins Jr. wrote: OnMon, Sep 22, 2014 at 9:04 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss [mailto:es-discuss-boun...@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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Idea for Strawman: separate the core standard library itself into modules
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. On 22 בספט׳ 2014, at 20:17, Brendan Eich bren...@mozilla.org wrote: Tab Atkins Jr. wrote: OnMon, Sep 22, 2014 at 9:04 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss [mailto:es-discuss-boun...@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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Idea for Strawman: separate the core standard library itself into modules
On Mon, Sep 22, 2014 at 3:30 PM, Benjamin Grurnbaum ing...@gmail.com wrote: With libraries like Knockout utilizing 'with', I'm not sure it'll go away anytime soon. Adding monocle mustache to a future ES might help with getting rid of it. ;) Nathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Idea for Strawman: separate the core standard library itself into modules
Not deprecated -- any reason you brought it up in the context of 'with'? /be John Barton wrote: Is __proto__ deprecated by TC39? The spec says otherwise. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Idea for Strawman: separate the core standard library itself into modules
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. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Idea for Strawman: separate the core standard library itself into modules
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. On 23 בספט׳ 2014, at 00:07, Brendan Eich bren...@mozilla.org wrote: Not deprecated -- any reason you brought it up in the context of 'with'? /be John Barton wrote: Is __proto__ deprecated by TC39? The spec says otherwise. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Idea for Strawman: separate the core standard library itself into modules
Please show an example of the code you're using __proto__ in. I'm sure it can be rewritten with Object.setPrototypeOf. 23.09.2014, 01:46, "Jasper St. Pierre" jstpie...@mecheye.net: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.On Mon, Sep 22, 2014 at 3:21 PM, Benjamin Grurnbaum ing...@gmail.com wrote: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. On 23 בספט׳ 2014, at 00:07, Brendan Eich bren...@mozilla.org wrote: Not deprecated -- any reason you brought it up in the context of 'with'? /be John Barton wrote: Is __proto__ deprecated by TC39? The spec says otherwise. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss-- Jasper,___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Idea for Strawman: separate the core standard library itself into modules
A way to start would add new built-ins only in modules. jjb On Mon, Sep 22, 2014 at 12:15 PM, Isiah Meadows impinb...@gmail.com 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. On Sep 22, 2014 3:10 PM, Isiah Meadows impinb...@gmail.com wrote: @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. On Sep 22, 2014 1:18 PM, Brendan Eich bren...@mozilla.org wrote: Tab Atkins Jr. wrote: OnMon, Sep 22, 2014 at 9:04 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss [mailto:es-discuss-boun...@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. /be ___ 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
Re: Idea for Strawman: separate the core standard library itself into modules
Until modules are shipping in engines we will have to continue to add globals. On Sep 22, 2014 8:03 PM, John Barton johnjbar...@google.com wrote: A way to start would add new built-ins only in modules. jjb On Mon, Sep 22, 2014 at 12:15 PM, Isiah Meadows impinb...@gmail.com 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. On Sep 22, 2014 3:10 PM, Isiah Meadows impinb...@gmail.com wrote: @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. On Sep 22, 2014 1:18 PM, Brendan Eich bren...@mozilla.org wrote: Tab Atkins Jr. wrote: OnMon, Sep 22, 2014 at 9:04 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: es-discuss [mailto:es-discuss-boun...@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. /be ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Idea for Strawman: separate the core standard library itself into modules
On Mon, Sep 22, 2014 at 8:17 PM, Erik Arvidsson erik.arvids...@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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
