I've never liked the |= approach, it's not very readable. I like the ?= operator from CoffeeScript, though. I tend to agree with the conventional wisdom (I think it's the conventional wisdom?) that the existential operator is too immature for JS and needs more research, but an existential assignment operator might be a different matter (I've not thought it through, though).
Best, Joe On Mon, Aug 10, 2015 at 9:43 AM, Fabrício Matté <ultco...@gmail.com> wrote: > What you've described seems very similar to PHP's static variables > <http://php.net/manual/en/language.variables.scope.php#language.variables.scope.static>. > They are very nice syntactic sugar, in my opinion. > I'm just not sure if this is worth adding new syntax to the language, as > there is already a pretty standard approach: > > ```js > var tmp; > function intersect_vector() { > tmp = tmp || new Vector(); > // ... > } > ``` > > Or with CoffeeScript: > > ```cs > tmp = null; > intersect_vector = -> > tmp ?= new Vector(); > # ... > ``` > > Though, static variables would remove this boilerplate and make it easier > to reason about a given binding's scope. I believe they would be a nice > addition to the language. > > /fm > > On Mon, Aug 10, 2015 at 1:16 PM, joe <joe...@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@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
