On Oct 7, 2011, at 6:51 AM, Mikeal Rogers wrote:
> On Thu, Oct 6, 2011 at 5:08 AM, Brendan Eich <bren...@mozilla.com> wrote:
> On Oct 4, 2011, at 10:52 AM, Mikeal Rogers wrote:
>
> > But, some of them simply double the semantics and syntax in the language
> > without a path to deprecate previous syntax. I'm a big fan of let, but if
> > you don't deprecate var we're going to have to contend with new programmers
> > keeping two sets of scoping rules in their head.
>
> You mean by deprecate what, exactly?
>
> Web JS is full of var. Making any attempt to migrate a big hunk of it to ES6
> require replacing all 'var' with 'let' is a huge tax, since scoping works
> differently.
>
> Ok, how about saying if you use 'let' in a function or at top level, you can
> no longer use 'var'? That's less of a tax on average, but for a long program
> or single function, it's as bad.
>
> 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).
> My main point was that syntax is hard. But syntax is UI and JS's UI has real
> usability bugs. I'm glad you find it easy to teach. That's not the only
> consideration though, because after people learn a language, as they keep
> using it they do progress to become fluent, even expert, at it, and its
> usability problems come to the fore.
>
> Semantics for experts is fine so long as the syntax doesn't confuse beginning
> to intermediate programmers. Like I said, I think the destructuring proposal
> is a great example of syntax that makes the semantics behind it obvious
> especially when compared to what it takes to accomplish the same task now.
>
> I would contrast that with generators. With ES5's forEach, map and filter,
> which are quite simple and obvious,
The meanings of the optional parameters are not super-obvious, but ok.
> 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.)
> 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.
> 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.
> 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.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
