Luke Scott wrote:
Currently you can do this anyway:
const C = class {};
if (someCondition) {
C = class OtherC {};
}
You can't: const is assign-once in ES6, and only from the initialiser in
the declaration.
/be
___
es-discuss mailing list
On 3/5/15 11:13 AM, Allen Wirfs-Brock wrote:
Editorially it would be a trivial change to make class declaration
produce immutable bindings.
Just to be clear, this would make class declarations behave differently
from builtins, both the ES kind and the IDL kind, right?
I'm not saying that's
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Boris
Zbarsky
Just to be clear, this would make class declarations behave differently from
builtins, both the ES kind and the IDL kind, right?
I think that would be true if your mental model of built-ins is that, in the
Just to be clear, this would make class declarations behave differently
from builtins, both the ES kind and the IDL kind, right?
I'm not saying that's a problem necessarily, but worth keeping in mind.
Good point. I think that we need to be looking ahead toward const class,
and leave ES6
On Mar 5, 2015, at 8:50 AM, Domenic Denicola wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Boris
Zbarsky
Just to be clear, this would make class declarations behave differently from
builtins, both the ES kind and the IDL kind, right?
I think that would
However, the double-binding issue makes this weirder. If non-const-class
declarations were like non-const-function declarations, where there is only
one binding per defining occurrence, then I would fully agree. But this
issue of one defining occurrence creating two bindings that can diverge
On 5 March 2015 at 04:57, Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
This is novel weirdness.
In C++/Java/C# etc. you don't see it because the corresponding
declarations create immutable bindings. I agree that it would have been
nice of we could have done that.
Hi Kevin,
If it were just a question of non-const-classes being too mutable, well,
they're everywhere already ridiculously too mutable in line with most
things in JS. It would be coherent to wait for const classes to repair the
mutability of the binding at the same time it repairs the mutability
On Mar 5, 2015, at 2:52 AM, Erik Arvidsson wrote:
Traceur does not give any history on this but I also remember having this
discussion in a f2f meeting. It was all about js has always been mutable,
lets not change that. If you want immutability you have it with `const f =
class {}`.
I
Erik Arvidsson wrote:
Traceur does not give any history on this but I also remember having
this discussion in a f2f meeting. It was all about js has always been
mutable, lets not change that. If you want immutability you have it
with `const f = class {}`.
Yeah, that fits the groove laid down
On Mar 5, 2015, at 9:20 AM, Kevin Smith zenpars...@gmail.com wrote:
However, the double-binding issue makes this weirder. If non-const-class
declarations were like non-const-function declarations, where there is only
one binding per defining occurrence, then I would fully agree. But this
On Thu, Mar 5, 2015 at 1:40 PM Luke Scott l...@cywh.com wrote:
On Mar 5, 2015, at 9:20 AM, Kevin Smith zenpars...@gmail.com wrote:
However, the double-binding issue makes this weirder. If non-const-class
declarations were like non-const-function declarations, where there is only
one binding
Traceur does not give any history on this but I also remember having this
discussion in a f2f meeting. It was all about js has always been mutable,
lets not change that. If you want immutability you have it with `const f =
class {}`.
On Thu, Mar 5, 2015 at 9:51 AM Andreas Rossberg
On Wed, Mar 4, 2015 at 6:41 AM, Andreas Rossberg rossb...@google.com
wrote:
[...]
(On the other hand, I do think that it probably was a serious mistakes to
make class bindings mutable.)
Will be part of the const class proposal from
http://wiki.ecmascript.org/doku.php?id=harmony:classes#const
On Mar 4, 2015, at 4:21 AM, Jason Orendorff wrote:
Oops, accidentally sent this only to Allen.
and I replied as follows:
On Mar 3, 2015, at 9:34 AM, Jason Orendorff wrote:
On Mon, Mar 2, 2015 at 5:54 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Pretty much everyone I've seen
Allen Wirfs-Brock wrote:
This is novel weirdness.
In C++/Java/C# etc. you don't see it because the corresponding
declarations create immutable bindings. I agree that it would have
been nice of we could have done that.
Why could we not have?
I asked this up-thread. What was the rationale
Andreas Rossberg wrote:
For the record, I strongly dislike the function behaviour. Turning a
function expression into a declaration silently changes the meaning of
internal recursive references, in ways that many people find very
surprising. That is an unnecessary pitfall.
Also for the
I guess we are just going to disagree here. Double bindings with
mutability still seem clearly bad. I can't make sense of the rationale
that classes can cope with every external binding being mutable except
for, somehow, their own name, and we're doing users a favor by
protecting them from
Oops, accidentally sent this only to Allen.
-- Forwarded message --
From: Jason Orendorff jason.orendo...@gmail.com
Date: Tue, Mar 3, 2015 at 11:34 AM
Subject: Re: Class double-bind
To: Allen Wirfs-Brock al...@wirfs-brock.com
On Mon, Mar 2, 2015 at 5:54 PM, Allen Wirfs-Brock al
For the record, I strongly dislike the function behaviour. Turning a
function expression into a declaration silently changes the meaning of
internal recursive references, in ways that many people find very
surprising. That is an unnecessary pitfall.
Your argument essentially is that you want to
On Mon, Mar 2, 2015 at 5:54 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I didn't take the time to come up with a real example. But code within a
class body that refers to the containing class is something I have seem many
times. Some of the most common places you see this is in
Allen Wirfs-Brock wrote:
That's precisely what I thought, until I started thinking about what
it'll actually be like to use this feature as a programmer.
To me, this issue explains why functions are the way they are.
Not my understandings. Function declarations are the way they are
A simple solution is to make:
class Foo { /* ... */ }
equivalent to:
const Foo = class Foo { /* ... */ }
instead of the equivalent desugaring with `let`. That way, anyone who want to
play with a same-named external binding must be explicit about their intention:
let Foo = class {
Claude Pache wrote:
A simple solution is to make:
class Foo { /* ... */ }
equivalent to:
const Foo = class Foo { /* ... */ }
instead of the equivalent desugaring with `let`.
The ES6 design has classes as sugar, which is an imprecise slogan, but
useful. For some reason we settled
All else being equal, your suggestion seems like the obviously right thing,
on at least consistency and least surprise grounds.
I know we discussed this. Anyone remember why we didn't do what Jason
suggests? My memory of counter-arguments here is blank.
On Mon, Mar 2, 2015 at 1:07 PM, Jason
Classes are specified to have an immutable inner binding even if they
also declare a mutable lexical binding in the enclosing scope:
class Foo {
foo() {
// immutable inner binding 'Foo' is in scope here
}
}
// mutable lexical binding 'Foo' is in scope here
Classes are more similar to function expressions which do have an internal
const binding.
One way to desugar ClassDeclaration is to desugar it into a let binding for
a ClassExpression. [1]
let Foo = class Foo extends expr {};
I would prefer if we didn't change the spec, not because I think it
see belolw
On Mar 2, 2015, at 1:35 PM, Erik Arvidsson wrote:
Classes are more similar to function expressions which do have an internal
const binding.
One way to desugar ClassDeclaration is to desugar it into a let binding for a
ClassExpression. [1]
let Foo = class Foo extends expr
On Mon, Mar 2, 2015 at 4:15 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
and conversely if we have something like this:
class Bar {
constructor(n) {this.n=n}
static get const() {return 42);
op(x) { return new Bar(Bar.const )}
};
the inner workings of the class would get
On Mar 2, 2015, at 3:14 PM, Jason Orendorff wrote:
On Mon, Mar 2, 2015 at 4:15 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
and conversely if we have something like this:
class Bar {
constructor(n) {this.n=n}
static get const() {return 42);
op(x) { return new Bar(Bar.const
30 matches
Mail list logo
