06:11 | <whosy> | I seem to recall hearing about reducing the number of new globally scoped objects, instead requiring they be explicitly imported as a module. Though now I can't figure out any source for this. Is this/will this be a thing? |
07:26 | <Ashley Claymore> | https://github.com/tc39/proposal-built-in-modules tc39/proposal-built-in-modules Afaik conversation hasn't happened much in last 5 years |
07:28 | <Ashley Claymore> | All current active proposals that add new names are being proposed to add either to an existing namespace/prototype. Or, in some cases, a new global name |
07:29 | <whosy> | Ah, thank you. |
07:30 | <whosy> | I'm interested given the possibility of collisions with existing libraries. An import would do well to solve the problem, but if the proposal is inactive then it might not be the solution I'd hoped. |
07:32 | <whosy> | This is regarding the Random Functions proposal, where I expect a global 'Random' might be too common to avoid collisions. Though I've not looked into it too deeply; this was just on my mind. |
07:34 | <Ashley Claymore> | If there turns out to be web compat issues a different name will be chosen |
07:36 | <Ashley Claymore> | Introducing built in modules would be a fairely large change to the language, so any proposal that wants to try and be the first suddenly becomes a much larger proposal |
07:36 | <whosy> | Fair enough. Just looking into it on a surface level I found: Which seems to introduce a |
07:39 | <Ashley Claymore> | things would only be breaking if there was an app doing something like:
|
07:39 | <Ashley Claymore> | an uncommon pattern for more modern apps |
07:40 | <whosy> | Thanks, that's good to know. I appreciate the help. |
07:42 | <Ashley Claymore> | np! |
17:25 | <bakkot> | yeah generally speaking collisions with libraries are not, in themselves, breaking |