How to modify the scope chain without `with` ?

Isiah Meadows isiahmeadows at
Mon Feb 22 14:26:54 UTC 2016

Okay. Now I understand what you're wanting. That's something that I'd
expect would be expensive, but I'm not fundamentally against it. I'm into
performance as well (and not just "I'm into it because it sounds bad if I'm
not"), but performance is a weird beast at times. I've found that
occasionally, the more dynamic features also help tremendously. Also,
strict typing is mostly useful if you're writing something at scale. I tend
to lean to dynamic features in smaller things, and static style in larger
libraries and applications. I see benefits to both.

Back to the original topic, I feel swapping the global is potentially
dangerous, but you should hopefully know what you're doing if you do.

On Mon, Feb 22, 2016, 09:04 Coroutines <coroutines at> wrote:

> On Mon, Feb 22, 2016 at 4:07 AM, Isiah Meadows <isiahmeadows at>
> wrote:
> > FYI, this part might not work as you might expect. I've already been
> > tripped up by similar.
> >
> > ```js
> > var o = {
> >   index: 0,
> >   func() { return this.index++ },
> > }
> >
> > with (o) {
> >   func() // TypeError: Cannot read property 'index' of undefined
> > }
> > ```
> To me this is expected...  I am accustomed to 'use strict'.
> > The other reasons `with` is deprecated are because dynamic scoping is
> > extremely hard to optimize and it's no longer obvious what variables
> > are defined in that block (static analysis no longer works).
> All I'm proposing is that we be given the ability to replace the
> global scope/Object by assigning to a special reference (_ENV = {}) -
> which would be scoped to the block, not forever-changed throughout the
> entire project/runtime.  It shouldn't change the layout of how the
> global scope is referenced on the stack in any implementation (v8?
> Chakra?).  And then of course that global scope object could be
> prototyped like any other object to provide inheritance/additional
> scoping.
> I am used to having this control in Lua - it works really nicely
> there.  I hate to be "that guy" but I've seen this used to help people
> manage and keep their code readable.  It's all just managing
> namespaces.  If I'm writing a module that defines a lot of Math
> functions I want the scope I define these functions in to be imbued
> with the existing facilities from `Math`.  I want to directly invoke
> cos() not Math.cos().  From the point of view of my math-related code
> I don't want to have the main, global perspective of the script that
> is loading my module.  I might make use of other modules that do not
> have a Math focus, and for that I will associate identifiers that go
> with their function: let log = require('logging');
> To me this makes perfect sense, but the only way to do this (assuming
> we never use `with` again) is for every module to be referenced
> through a local, possibly shortened identifier and not touch the
> global scope at all.  Repeating identifiers over and over is not
> concision, it's not DRY - it's tedium.  I cannot be as expressive as I
> want, nor can I make use of the environment I need - and mess it up
> (temporarily).  On that 2nd note, I wish module loading were as simple
> as this to prevent global destruction:
> Loading a module should be:
> 1) Resolve to the path of the module (or <script> href?)
> 2) Fetch/read the file/script
> 3) Construct a global env/object that inherits from the existing
> environment
> 4) Run the script as a function/block within this new environment
> 5) Cache the `exports` value.
> 6) Return this value to the caller
> I think Node does this essentially (which is why we have a `global`
> reference to the "real" environment), but "normal" JS does not.  We
> hide what we can in closures, but code that does not export in the
> many fabulous ways we've come up with can have a lasting effect on the
> global scope.  I like that to explicitly mutilate the global scope
> (not module-scope) I have to type `global[prop] = ...`.
> Personal opinion: I prefer runtime analysis to static analysis.  Not a
> huge fan of type annotations and "strong mode" trying to cement a
> type's ABI to eek out more performance.  I mean yes, optimizations are
> great but I'd rather have flexiblity to express myself how I want over
> limitations that save me negligible amounts of time..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list