@Alex Kocharin: I would't call the functions like time. It was only a very simple example. Often my functions would be called from outside so I wouldn't be able to pass the values. Also the main reason I want this is for optimizations, so as you pointed out, can't use the ugly with.
On Tue, Dec 24, 2013 at 10:00 PM, <[email protected]> wrote: > Send es-discuss mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.mozilla.org/listinfo/es-discuss > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of es-discuss digest..." > > Today's Topics: > > 1. Deep Object Observing (Eric Devine) > 2. Re: Deep Object Observing (Brendan Eich) > 3. local variables with inherited values (raul mihaila) > 4. Re: local variables with inherited values (Alex Kocharin) > 5. Re: local variables with inherited values (Brendan Eich) > > > ---------- Forwarded message ---------- > From: Eric Devine <[email protected]> > To: [email protected] > Cc: > Date: Mon, 23 Dec 2013 21:26:09 -0500 > Subject: Deep Object Observing > New to the forum here. > > I've been experimenting with the Polymer-Project "prolyfill" > Node.prototype.bind() function, and have rolled an implementation of my own > that is dependent on Object.observe and MutationObserver. > > The function binds to a path relative to a given object, so it must not > only observe the descendant property, but it also must observe every object > between and be able to recursively reconstruct the "chain" if a "link" is > replaced, and recursively unobserve the replaced "links". > > The recursive function to accomplish this is simple enough, but the memory > footprint has the potential to become expensive when scaled. > > I feel this feature is a good candidate for a native implementation. Is > there any plans to bring the concept of deep object observing to ES? > > Thanks for your time, > Eric > > > ---------- Forwarded message ---------- > From: Brendan Eich <[email protected]> > To: Eric Devine <[email protected]> > Cc: [email protected] > Date: Mon, 23 Dec 2013 22:01:29 -0500 > Subject: Re: Deep Object Observing > Eric Devine wrote: > >> The recursive function to accomplish this is simple enough, but the >> memory footprint has the potential to become expensive when scaled. >> >> I feel this feature is a good candidate for a native implementation. Is >> there any plans to bring the concept of deep object observing to ES? >> > > No, but I have to ask: why do you think native would be better than JS > self-hosted in terms of memory footprint? > > Possibly related: http://swannodette.github.io/2013/12/17/the-future-of- > javascript-mvcs/. > > /be > > > > ---------- Forwarded message ---------- > From: raul mihaila <[email protected]> > To: es-discuss <[email protected]> > Cc: > Date: Tue, 24 Dec 2013 19:10:19 +0200 > Subject: local variables with inherited values > Merry Christmas! > > Did you consider adding a way for variables to automatically get the value > from a variable with the same name from the parent execution context? > > (function () { > var x = 2; > > (function () { > local x; // x = 2 > x = 100; > x; // x = 100 > > local y; // maybe throw since y was not found anywhere > })(); > > x; // x = 2 > })(); > > This would be useful when optimizing the code so that the variables are as > local as possible. Especially useful with calling functions (multiple > times) or working heavily with collections from the outer context in the > inner functions. > > > ---------- Forwarded message ---------- > From: Alex Kocharin <[email protected]> > To: es-discuss <[email protected]> > Cc: > Date: Tue, 24 Dec 2013 21:34:03 +0400 > Subject: Re: local variables with inherited values > > ;(function() { > var x = 2 > > ;(function(x) { > x = 100 > x // x = 100 > })(x) > > x // x = 2 > })() > > Wow, it works already. You just have to write a bit less semicolons there. > Merry Christmas! :) > > Also this: > > ;(function() { > var x = 2 > > with({x: x}) { > x = 100 > x // x = 100 > } > > x // x = 2 > })() > > But js engines don't appreciate that one. :( > > > 24.12.2013, 21:10, "raul mihaila" <[email protected]>: > > Merry Christmas! > > Did you consider adding a way for variables to automatically get the value > from a variable with the same name from the parent execution context? > > (function () { > var x = 2; > > (function () { > local x; // x = 2 > x = 100; > x; // x = 100 > > local y; // maybe throw since y was not found anywhere > })(); > > x; // x = 2 > })(); > > This would be useful when optimizing the code so that the variables are as > local as possible. Especially useful with calling functions (multiple > times) or working heavily with collections from the outer context in the > inner functions. > , > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > > ---------- Forwarded message ---------- > From: Brendan Eich <[email protected]> > To: raul mihaila <[email protected]> > Cc: es-discuss <[email protected]> > Date: Tue, 24 Dec 2013 12:53:36 -0500 > Subject: Re: local variables with inherited values > ES4 had let (x = x) ... forms (where ... was an expression or a body), but > for ES6 we agreed on the temporal dead zone: > > { let x = 'outer'; { /* x throws here */; let x = 'inner'; alert(x); } > alert(x); } > > which will alert 'inner' then 'outer'. There is no way to initialize the > inner x from the outer. The reason for temporal dead zone is given by > counterexamples against the alternatives. Quoting from Waldemar Horwant at: > > https://mail.mozilla.org/pipermail/es-discuss/2008-October/007807.html > > """ > There are four ways to do this: > > A1. Lexical dead zone. References textually prior to a definition in the > same block are an error. > A2. Lexical window. References textually prior to a definition in the > same block go to outer scope. > B1. Temporal dead zone. References temporally prior to a definition in > the same block are an error. > B2. Temporal window. References temporally prior to a definition in the > same block go to outer scope. > > Let's take a look at an example: > > let x = "outer"; > function g() {return "outer"} > > { > g(); > function f() { ... x ... g ... g() ... } > f(); > var t = some_runtime_type; > const x:t = "inner"; > function g() { ... x ... } > g(); > f(); > } > > B2 is bad because then the x inside g would sometimes refer to "outer" and > sometimes to "inner". > > A1 and A2 introduce extra complexity but doesn't solve the problem. You'd > need to come up with a value for x to use in the very first call to g(). > Furthermore, for A2 whether the window occurred or not would also depend > on whether something was a function or not; users would be surprised that x > shows through the window inside f but g doesn't. > > That leaves B1, which matches the semantic model (we need to avoid > referencing variables before we know their types and before we know the > values of constants). > """ > > Raul, you seem to want A2 or possibly B2, I'm not sure which. I hope this > helps make the case for B1, temporal dead zone. > > It may seem unusual compared to languages that do not have closures, or > that require declarations to come before any closures. > > /be > > raul mihaila <mailto:[email protected]> >> December 24, 2013 12:10 PM >> Merry Christmas! >> >> Did you consider adding a way for variables to automatically get the >> value from a variable with the same name from the parent execution context? >> >> (function () { >> var x = 2; >> (function () { >> local x; // x = 2 >> x = 100; >> x; // x = 100 >> >> local y; // maybe throw since y was not found anywhere >> })(); >> >> x; // x = 2 >> })(); >> >> This would be useful when optimizing the code so that the variables are >> as local as possible. Especially useful with calling functions (multiple >> times) or working heavily with collections from the outer context in the >> inner functions. >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
