es-discuss Digest, Vol 82, Issue 95

raul mihaila raul.mihaila at gmail.com
Wed Dec 25 03:29:17 PST 2013


@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-request at mozilla.org> wrote:

> Send es-discuss mailing list submissions to
>         es-discuss at 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-request at mozilla.org
>
> You can reach the person managing the list at
>         es-discuss-owner at 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 <devineej at gmail.com>
> To: es-discuss at 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 <brendan at mozilla.com>
> To: Eric Devine <devineej at gmail.com>
> Cc: es-discuss at 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.mihaila at gmail.com>
> To: es-discuss <es-discuss at 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 <alex at kocharin.ru>
> To: es-discuss <es-discuss at 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.mihaila at 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 the
> inner functions.
> ,
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> ---------- Forwarded message ----------
> From: Brendan Eich <brendan at mozilla.com>
> To: raul mihaila <raul.mihaila at gmail.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> 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:raul.mihaila at gmail.com>
>> 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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131225/5da0dae5/attachment.html>


More information about the es-discuss mailing list