Fwd: local variables with inherited values
What I want is both similar to A2 and B2, but it's different in that there
is only 1 scope for the inner variable. The inner variable is just a local
variable, but it's initialized in the hoisting process with the value from
the outer scope. Initially I was thinking only about var scoped variables
but I think this should work for the let scoped variables as well. We would
need a new keyword then. Adds some complexity but at least there's only one
scope.
I didn't study the details about let scope variables in the current spec
but I understand that this should throw:
{
(function () {
x; // throws - B1 case
})();
x; // x = undefined, right? - not A1 case because it doesn't throw
let x = 10;
};
Currently in FF there's no error here, x is undefined. In Chrome there's an
error about some extended mode which, from what I understand, doesn't exist
anymore.
Currently I achieve what I want by defining a local variable whose name is
prefixed with 'local' and assigning it the value I need. It's bad if I want
to do the same in multiple execution levels. My proposal is far more
readable because it looks less weird.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: local variables with inherited values
On Tue, Dec 24, 2013 at 7:53 PM, Brendan Eich bren...@mozilla.com wrote: ES4 had let (x = x) ... forms (where ... was an expression or a body), but for ES6 we agreed on the temporal dead zone: Or maybe there's no need for a new keyword :). Not sure I would like an additional body though. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: es-discuss Digest, Vol 82, Issue 95
@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, es-discuss-requ...@mozilla.org wrote:
Send es-discuss mailing list submissions to
es-discuss@mozilla.org
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
es-discuss-requ...@mozilla.org
You can reach the person managing the list at
es-discuss-ow...@mozilla.org
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 devin...@gmail.com
To: es-discuss@mozilla.org
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 bren...@mozilla.com
To: Eric Devine devin...@gmail.com
Cc: es-discuss@mozilla.org
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 raul.miha...@gmail.com
To: es-discuss es-discuss@mozilla.org
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 a...@kocharin.ru
To: es-discuss es-discuss@mozilla.org
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 raul.miha...@gmail.com:
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
Re: es-discuss Digest, Vol 82, Issue 95
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" raul.miha...@gmail.com:@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, es-discuss-requ...@mozilla.org wrote:Send es-discuss mailing list submissions to es-discuss@mozilla.org 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 es-discuss-requ...@mozilla.org You can reach the person managing the list at es-discuss-ow...@mozilla.org 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 devin...@gmail.comTo: es-discuss@mozilla.orgCc: Date: Mon, 23 Dec 2013 21:26:09 -0500Subject: 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 bren...@mozilla.comTo: Eric Devine devin...@gmail.com Cc: es-discuss@mozilla.orgDate: Mon, 23 Dec 2013 22:01:29 -0500Subject: Re: Deep Object ObservingEric 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 raul.miha...@gmail.comTo: es-discuss es-discuss@mozilla.org Cc: Date: Tue, 24 Dec 2013 19:10:19 +0200Subject: 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 = 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 a...@kocharin.ruTo: es-discuss es-discuss@mozilla.org Cc: Date: Tue, 24 Dec 2013 21:34:03 +0400Subject: 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" raul.miha...@gmail.com: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
Overly complicated Array.from?
Hi,
I was reading the current spec for Array.from and it felt too
complicated to me. Currently, at a high-level it reads like:
1) if the argument is iterable (@@iterable symbol), create a fresh array
made of the values iterated on with the iterator
2) (step9) if the object is array-like, len = [[Get]] ('length') and
from 0 to len-1, copy the values of the array-like in a fresh array to
be returned.
Note that between the two parts, a good share of spec is duplicated.
For the rationale, the wiki states [1]:
There are many array-like objects in JS (arguments objects, DOM
NodeLists, arrays from separate windows, typed arrays) and no simple way
to convert one of these to an instance of Array in the current window;
this is the rationale behind a simple conversion function (Array.from).
I think that if all of these objects had a good default @@iterable,
there wouldn't be a need for the array-like part of Array.from.
The good default most likely being based on .length, etc.
David
[1] http://wiki.ecmascript.org/doku.php?id=strawman:array_extras
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Overly complicated Array.from?
On Wed, Dec 25, 2013 at 7:33 PM, David Bruant bruan...@gmail.com wrote:
Hi,
I was reading the current spec for Array.from and it felt too complicated
to me.
I've been following the specification of Array.from very closely since the
day Dave and I first designed it and it's exactly as complicated as it
needs to be for what it needs to be able to do.
Currently, at a high-level it reads like:
1) if the argument is iterable (@@iterable symbol), create a fresh array
made of the values iterated on with the iterator
2) (step9) if the object is array-like, len = [[Get]] ('length') and from
0 to len-1, copy the values of the array-like in a fresh array to be
returned.
Note that between the two parts, a good share of spec is duplicated.
For the rationale, the wiki states [1]:
There are many array-like objects in JS (arguments objects, DOM
NodeLists, arrays from separate windows, typed arrays) and no simple way to
convert one of these to an instance of Array in the current window; this is
the rationale behind a simple conversion function (Array.from).
I think that if all of these objects had a good default @@iterable, there
wouldn't be a need for the array-like part of Array.from.
The good default most likely being based on .length, etc.
The array-like part is for all of those objects that _won't_ have an
@@iterator, for one reason or another, and for useful shimming in ES5
runtimes. Array.from can be implemented today for array-likes without
Symbols + @@iterator and the same code using Array.from will work correctly
with the built-in Array.from once those `if (typeof Array.from ===
undefined) {...` check evaluate to false.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
