On 6 December 2012 22:26, Claus Reinke claus.rei...@talk21.com wrote:
I was hoping for something roughly like
let lhs = rhs; statements
// non-recursive, scope is statements
let { declarations }; statements// recursive, scope is
declarations and statements
Problem is
On 6 December 2012 18:38, Rick Waldron waldron.r...@gmail.com wrote:
I agree with other voices in this thread that in general, returning
'this' rather is an anti pattern.
The evidence I've brought to this discussion shows that the most widely used
and depended upon libraries heavily favor the
On 6 December 2012 17:54, Kevin Smith khs4...@gmail.com wrote:
Note, however, that you still assume some hack in the semantics with
the if it exists part. To avoid that, you need to divorce the import
syntax from the naming-an-external-module syntax -- which I'd actually
prefer anyway, and
On Thu, Dec 6, 2012 at 1:46 PM, Brendan Eich bren...@mozilla.org wrote:
David Herman wrote:
Cool, definitely want the plain identifier form, it's part of the
binding (and destructuring) pattern language.
Well, the thing is it isn't consistent with the destructuring meaning:
dropping the
Feel free to suggest alternatives, but forgive me if I'm not willing to
respond to every opinion on this one. :}
How about:
import ga as ga;
to import the whole module, and
import ga as { foo, bar };
to import just parts of the module. I feel like this makes a lot of sense, and
On Dec 7, 2012, at 2:58 AM, Herby Vojčík wrote:
tl;dr: new and super run different code for same constructor; shows the
problem, proposes the solution that assures it always run the same code,
giving precedence to .constructor over the function.
Short response. The problem you identify
The current behavior is needed to enable to following repair:
--- some existing buggy library
class Foo ;
-
-- some importing and repairing library --
const BadFoo = Foo;
Foo = function .;
Foo.prototype = BadFoo.prototype;
BadFoo.prototype.constructor = Foo;
Jeff Walden wrote:
On 12/04/2012 03:57 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
The timing of copying is only an issue if the function actually assigns to a
formal parameter. Such assignments should be pretty easy to (conservatively)
statically check for.
I'm telling you what
Andreas Rossberg wrote:
On 6 December 2012 18:38, Rick Waldronwaldron.r...@gmail.com wrote:
I agree with other voices in this thread that in general, returning
'this' rather is an anti pattern.
The evidence I've brought to this discussion shows that the most widely used
and depended upon
Hello
it seems to me that with new language construct jn ES6, there sort-of is
a spartan support for cascading.
Instead of
a[i].set.add(bar);
a[i].set.forEach(...);
one can do
{ let s = a[i].set;
s.add(bar);
s.forEach(...);
}
or
(s = a[i].set) = {
s.add(bar);
tl;dr: new and super run different code for same constructor; shows the
problem, proposes the solution that assures it always run the same code,
giving precedence to .constructor over the function.
Hello,
in the present state of the spec, the semantic of super(...) is defined
to call
11 matches
Mail list logo
