Language modes (Was: Block scoping and redeclarations)

# Andreas Rossberg (14 years ago)

That's not to say that I couldn't live with more fine-grained rules, I just don't consider them worthwhile. Ultimately, we want to morally deprecate "var" for Harmony mode, so introducing too many extra rules around it seems a bit unjustified, unless there is a very good reason.

Btw, we had this amusing discussion in July how to name the different language modes without stepping on people's toes. How about "classic", "strict", and "modern"?

> That's not to say that I couldn't live with more fine-grained rules, I
> just don't consider them worthwhile. Ultimately, we want to morally
> deprecate "var" for Harmony mode, so introducing too many extra rules
> around it seems a bit unjustified, unless there is a very good reason.

Btw, we had this amusing discussion in July how to name the different
language modes without stepping on people's toes. How about "classic",
"strict", and "modern"?

/Andreas

# Allen Wirfs-Brock (14 years ago)

On Aug 24, 2011, at 2:08 AM, Andreas Rossberg wrote:

Btw, we had this amusing discussion in July how to name the different language modes without stepping on people's toes. How about "classic", "strict", and "modern"?

The "modern" mode won't seem very modern twenty years from now.

On Aug 24, 2011, at 2:08 AM, Andreas Rossberg wrote:
>> 
> 
> Btw, we had this amusing discussion in July how to name the different
> language modes without stepping on people's toes. How about "classic",
> "strict", and "modern"?
> 

The "modern" mode won't seem very modern twenty years from now.

allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110824/c617e1e4/attachment.html>

# Mike Shaver (14 years ago)

On Wed, Aug 24, 2011 at 11:30 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

The "modern" mode won't seem very modern twenty years from now. allen

My understanding is that anything after the Middle Ages is fair game, and I see strict as the middle age between ES.now and ES.future. :-)

MIke

On Wed, Aug 24, 2011 at 11:30 AM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
> The "modern" mode won't seem very modern twenty years from now.
> allen

My understanding is that anything after the Middle Ages is fair game,
and I see strict as the middle age between ES.now and ES.future. :-)

MIke

# Brendan Eich (14 years ago)

On Aug 24, 2011, at 2:08 AM, Andreas Rossberg wrote:

That's not to say that I couldn't live with more fine-grained rules, I just don't consider them worthwhile. Ultimately, we want to morally deprecate "var" for Harmony mode, so introducing too many extra rules around it seems a bit unjustified, unless there is a very good reason.

Btw, we had this amusing discussion in July how to name the different language modes without stepping on people's toes. How about "classic", "strict", and "modern"?

I once made the mistake of using "_NEW" as a name part for an opcode in SpiderMonkey. Got old fast.

We want few modes, ideally only RFC4329 version numbers on one line, not a lattice. This is why Harmony is based on ES5 strict and we do not want an ES6 stricter strict ("use really strict").

The argument in July, which I was lucky enough to (mostly) miss, seemed spec jargon bikeshedding. "Extended mode" vs. something else.

But note that "extended" is timeless, and if we avoid refracting modes through one another, and keep to a linear regime, the spec does not need to distinguish ES6 "extended" from ES7. The spec version itself does that, and (modulo more convenient forms for HTML authors) the "6" in <script type="application/javascript;version=6"> means the same thing.

On Aug 24, 2011, at 2:08 AM, Andreas Rossberg wrote:

>> That's not to say that I couldn't live with more fine-grained rules, I
>> just don't consider them worthwhile. Ultimately, we want to morally
>> deprecate "var" for Harmony mode, so introducing too many extra rules
>> around it seems a bit unjustified, unless there is a very good reason.
> 
> Btw, we had this amusing discussion in July how to name the different
> language modes without stepping on people's toes. How about "classic",
> "strict", and "modern"?

I once made the mistake of using "_NEW" as a name part for an opcode in SpiderMonkey. Got old fast.

We want few modes, ideally only RFC4329 version numbers on one line, not a lattice. This is why Harmony is based on ES5 strict and we do not want an ES6 stricter strict ("use really strict").

The argument in July, which I was lucky enough to (mostly) miss, seemed spec jargon bikeshedding. "Extended mode" vs. something else.

But note that "extended" is timeless, and if we avoid refracting modes through one another, and keep to a linear regime, the spec does not need to distinguish ES6 "extended" from ES7. The spec version itself does that, and (modulo more convenient forms for HTML authors) the "6" in <script type="application/javascript;version=6"> means the same thing.

/be