<p dir="ltr"></p>
<p dir="ltr">/#!/JoePea<br>
On Feb 16, 2016 9:38 AM, "Coroutines" <<a href="mailto:coroutines@gmail.com">coroutines@gmail.com</a>> wrote:<br>
><br>
> On Tue, Feb 16, 2016 at 9:16 AM, /#!/JoePea <<a href="mailto:joe@trusktr.io">joe@trusktr.io</a>> wrote:<br>
> > /#!/JoePea<br>
> > On Feb 16, 2016 9:13 AM, "/#!/JoePea" <<a href="mailto:joe@trusktr.io">joe@trusktr.io</a>> wrote:<br>
> >><br>
> >> Seems like changing the global could lead to problems where a developer<br>
> >> might assumes certain globals but hey<br>
> ><br>
> > I meant: "but have" different ones. Importing things explicitly into modules<br>
> > (instead of (inherited) globals) helps better understand the requirements of<br>
> > a given piece of code imo.<br>
> ><br>
> >> different ones, which imho could make the use of globals even messier. I<br>
> >> imagine you would like Angular's $scope inheritance, which is sort of like<br>
> >> what you want<br>
> >> (<a href="https://github.com/angular/angular.js/wiki/Understanding-Scopes">https://github.com/angular/angular.js/wiki/Understanding-Scopes</a>).<br>
><br>
> I was just thinking about the `import` we gained in ES6.  In Perl and<br>
> Python you might have functions imported directly into the global<br>
> scope (of the current context) - so that it's easier to just write the<br>
> function name without the short reference you imported it in as:<br>
><br>
> cos(PI) vs Math.cos(Math.PI)  etc...</p>
<p dir="ltr">You could</p>
<p dir="ltr">```js<br>
let {cos, PI} = Math</p>
<p dir="ltr">console.log(cos(PI))<br>
```</p>
<p dir="ltr">><br>
> I was simply thinking it could give you the ability to choose how you<br>
> prefer to write that.  If you're not using several modules and the<br>
> code you're writing is quite focused in one area it might look cleaner<br>
> (less redundant) to import Math and have all its functions be<br>
> accessible as "globals".  If you are writing code that ties together<br>
> functions from Math, fs, and tls modules (for some reason??) it would<br>
> make sense to do the existing:<br>
><br>
> var fs = require('fs');<br>
> var tls = require('tls');<br>
> ...<br>
><br>
> Anyway, if we had control over the global scope/context/Object, it<br>
> would allow you to make these design decisions in an effort to write<br>
> code that I would sometimes view as cleaner.  What I think is<br>
> important is that you could have your existing scope inherit from the<br>
> "first" global scope, but when you assign to the current global scope<br>
> it is set there.  Your modifications don't extend globally to the rest<br>
> of the project.  Also if you want to isolate your current scope from<br>
> the global scope you don't have to have one inherit from the other -<br>
> you can break it's prototype (or never form it).  Again, as the other<br>
> guy pointed out - it's not a complete or even marginally safe<br>
> "sandbox" but all in all I think it's something we should have control<br>
> over if we want to simplfy how modules are created (for one) without<br>
> polluting the existing global scope/Object.<br>
><br>
> My responses are a bit wordy/disorganized...<br>
</p>