Static local variables

[myemailum14 at gmail.com]

Look at it this way

a = a + 1

is same as

a += 1

then it feels natural to say the same thing

a = a || 1

a ||= 1

then you can extend it like this

a ||= var1 || var 2 || var 3



On Mon, Aug 10, 2015 at 12:16 PM, joe <joeedh at gmail.com> wrote:

> I've been hesitant to bring up this idea, because even though I use it
> extensively as a language extension in my transpiler I'm not sure it is
> normatively correct.
>
> When I started my first major JS project four or five years ago, I noticed
> I was doing this a lot:
>
>     var intersect_vector_tmp = new Vector();
>
>     function intersect_vector(v1, v2) {
>         var tmp = intersect_vector_tmp .load(v1).sub(v2);
>         //do something
>         v1.add(tmp);
>     }
>
> Basically, I was doing the following transform:
>
> *  For each static local variable...
>     1. Build unique name from hash of lexical scope chain
>     2. Rename variable (along with references to it in the local hoisted
> scope).
>     3. Move it to module/global namespace.
>
> I ended up implemented this in my compiler as a sort of C-style static
> local variable.  Thus, the example above became:
>
>     function intersect_vector(v1, v2) {
>
>         static tmp = new Vector();
>
>         tmp.load(v1).sub(v2);
>         //do something
>         v1.add(tmp);
>     }
>
> There are, obviously, a great many problems here, starting with the fact
> that the variable's initializers are being evaluated outside of the scope
> they were declared in.  Unfortunately this pattern can be hard to avoid for
> high-performance code, so much so that if the transformation is done by
> hand you end up with a great deal of clutter.  This is especially annoying
> when dealing with classes, as the following file (with the statics
> transpiled out) illustrates:
>
>
> https://github.com/joeedh/fairmotion/blob/master/examples/vectormath_static_illustration.js
>
> This becomes a real pain after a while.  At one point I tried using shared
> object pools, but found that this didn't remove very much clutter because,
> in practice, each function had to have its own pool (usually one for each
> type of temporary object it uses).  This really does boil down to a lack of
> support for local stack allocation of temporary objects.
>
> Anyway, I just thought I'd put this out there. Who knows, maybe someone
> will invent perfect escape analysis for temporary const objects, and we
> won't need hackish language extensions such as this.
>
> What do people think? Too many normative problems?
>
> Best,
> Joe
>
> _______________________________________________
> 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/20150810/50177a83/attachment.html>