On Oct 12, 2011, at October 12, 201110:08 PM, Brendan Eich wrote:
>>
>>
>> This is exactly what I was getting at.
>
> Andreas Rossberg brought it up. We can put it on the agenda for the November
> meeting, but it could be better to discuss here first, if people have
> specific migration stories involving let and var (say, from Firefox add-on or
> browser JS).
I don't know what official capacity it was brought up in but i know Alex once
mentioned to me the idea of using modules to deprecate var. Basically, within a
module var is no longer allowed. That's another idea.
Either way, I think it should be a priority to have a deprecation strategy in
place for var in ES6, I don't have a strong opinion about what it should be.
>
>> I wonder why the semantics of generators can't be achieved in a way that is
>> clearer to less than expert programmers.
>
> What's the problem? You didn't say.
>
> The semantics of generators must be such that the compiler can tell when a
> function is a generator. So something is going to signify "this function is a
> generator".
>
> (We already went around the block with using "generator" as a keyword --
> that's not a reserved future word so it would need to be reserved as a
> breaking change, or possibly only if it comes after a line terminator, but
> then anonymous generators are still incompatible. I.e., you could have JS
> today of this form:
>
> x =
> generator
> (a, b)
> {
> }
>
> which if generator names a callable object and a and b are bound, is
> perfectly legal.)
A generator keyword is much clearer and avoids confusion but as you say, it's
not a reserved word and has practical issues.
The issues you bring up are serious, all I'm saying is that by attaching
additional semantics to function we continue to perpetuate confusion about what
functions are in javascript and reducing confusion, for me, is more important.
Others may not agree.
>> I also haven't touched classes yet. Just saying the word makes me cringe a
>> little, but once i get over my initial emotional reaction I think about how
>> difficult it is currently to juggle code that is using traditional
>> prototypical inheritance and code that is using an entirely different
>> pattern people use to hack class inheritance in today.
>
> What other pattern? The closure pattern is not really "incompatible", just
> different. You can even mix the two.
What I meant was, object A uses class style inheritance and class B uses
vanilla prototype inheritance and there isn't an obvious signal that they are
different or which style I should use if I'm going to extend them if I'm a less
than expert programmer.
This is something we might solve with classes in ES6.
>
>> Having just a syntax, even without any more semantics than people already
>> add today, *could* reduce that confusion.
>
> That was the hope. Seems like too many requirements, including ones we can't
> agree to meet now and yet also can't future-proof against, got piled on top.
IMO, ditch all the additional semantics. Make it pure cane sugar. It adds
clarity to the language around a pattern that is already popular. If people are
clamoring for all these extra semantics then it'll be obvious what should go in
by ES7.
>
>> I'm still on the fence about it because I'm so initially reactionary about
>> the word itself... "class".....
>
> Yes, I cringe a bit too. Would "factory" be better? It has the same problem
> as "generator", though -- it is not a future reserved word.
I don't think my, or your, apprehension to the word itself is representative of
most new users. We'll get over it, we have to, it's not like we're going to
start programming Dart :P
>
> /be
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
