If you're looking for optimizations, nested closures is not a place where you generally want to be. Create a function out of the scope and call it with all needed variables since function calling is cheap nowadays, and arguments already behave the way you're describing.
25.12.2013, 15:29, "raul mihaila" <[email protected]>:
@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 ObservingNew 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 valuesMerry 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 = 2x = 100;x; // x = 100local 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 = 100x // 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 = 2with({x: x}) {x = 100x // 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 = 2x = 100;x; // x = 100local 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
