Hi Allen,
What were the requirements for the global lexical scope? Is it written
somewhere I can read? I came up empty after a quick search of esdiscuss.org.
I think the whole point of ES6 lexical scoping is to limit scope to something
you can read in a given file (or script, or block, or eval, or unit of JS
code). Except, this breaks down for global top-level let/const/class. I argue
that if you want these variables to be visible across JS programs, you should
be using modules. The current spec makes this somewhat better than "var"s
because these variables are no longer properties on the global object, but it
punted and said that there is some magical lexical scope that wraps all
programs. I think it's more in the spirit of lexical scoping to have these
variables be limited to the program they're defined in (as if the entire
program were wrapped in {}). And it's more in the spirit of ES6 to share code
across programs using modules.
I think it's not helpful for you to threaten that our opinions are less useful
than a proof of impossibility when we are people who are both interested in the
JavaScript language and interested in implementing it well. I've spent > 8
hours today implementing the "global lexical tier", so I think it's helpful to
categorize my opinion as being slightly greater than "less useful than a proof
that the spec is impossible to implement". Sometimes the best ideas are those
that are negligent of "requirements".
Saam
> On Sep 1, 2015, at 11:39 AM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote:
>
>
> On Sep 1, 2015, at 11:04 AM, Geoffrey Garen wrote:
>
>>> The possible semantics of global lexical declarations was extensively
>>> explored by TC39 before we make the final design decisions for ES6. The
>>> scoping of global lexical declarations is something we spent many hours
>>> discussing over a span of several years, including:
>>
>> To be fair, some problems in design only become apparent after
>> implementation and use.
>>
>> For example, in the case of global lexical scope, implementing and testing
>> the details of the current ECMAScript specification led Saam to conclude —
>> and led me to agree — that the behavior was strange, and hard to reason
>> about.
>>
>> I hope you aren’t saying that ECMAScript decisions should become permanent
>> and irreversible prior to any implementation or adoption effort. In other
>> web standards, implementation and adoption guide specification — to the
>> benefit of the specification.
>>
>> Geoff
>
> What I'm saying is that this is more about "requirements" than
> implementations. There was a complex (and sometimes conflicting) set of
> requirements for the semantics of the new global declarations. The final
> design that TC39 accepted threaded the needle among those requirements. We
> were aware that some people (including some TC39 members) would probably find
> some aspects of the design might be strange or quirky. However, that tends to
> be the nature of solutions when dealing with complex requirements.
>
> Suggestions to change the design needs to address how each of those
> requirements can still met or why some of the requirements are not longer
> relevant. Evidence that the design is impossible to implement would be
> important news. But I don't think anybody has yet made that assertion.
> Observations that it is strange is less useful. So are alternative designs
> that are presented without consideration of all of the initial requirements.
>
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
