C. Scott Ananian
ecmascript at cscott.net
Mon Jun 30 10:01:04 PDT 2014
On Mon, Jun 30, 2014 at 7:14 AM, Andreas Rossberg <rossberg at google.com>
> > ...this is why I've been arguing strongly for consistent syntax
> > Static checking and lazy binding should be "value added features", not
> > something I have to think about every time I import a module.
> Painting over semantic differences by using the same syntax is not an
> improvement in usability. It decreases readability, and increases
> confusion and surprise. You probably weren't around when this was
> discussed last time, but the differences between importing from a
> "proper" module and importing from a singleton export object are not
> just in static checking. They create different bindings. The former
> creates an _alias_ for the variable from the module. The latter would
> need to destructure the property into a _new_ variable, i.e., would
> need to _copy_ its state. This leads to visibly different results when
> the variable is mutated (internally or externally).
Yes, I am aware of that. I also claim that in most module code this
difference is insignificant. That is, it continues to be best practice to
*avoid* creating circular dependencies in modules. Further, self-contained
modules will have no need to export lazy-bound references, even if they use
I *have* been around for these discussions. And my conclusion is that the
dogmatists are getting in the way. Just because there are *some*
differences between modules and objects doesn't mean that *all* users must
be confronted with them. Just because *some* modules may be defined in a
way to prevents robust checking of modules doesn't mean that *all* modules
must be prevented from doing so.
> Please assume that all these ideas have been discussed extensively,
> and carefully considered, in particular by Dave and Sam. And while I
> do not agree with all conclusions, the current design has gotten much
> more thought in it than many in this thread seem to assume. In
> particular, none of the suggestions made in this thread so far are
I agree that the discussion has gone in many circles. But it is also clear
that the consensus is fragile and the compromises not well-liked. I don't
know of a better way to make continued progress other than (a) proposing
tweaks to the existing compromise that might enhance its appeal, or (b)
continuing to discuss the trade-offs made in an effort to solidify the
We can decide that this checking is not worth it and drop it. But we
> cannot have our cake and eat it too.
Concretely I'm proposing that we drop only the "must" and "all" phrases
with respect to checking. I think we can come up with a design where
checking is "mostly" and "usually" possible. This will put the decision in
the hands of the code authors, who can either decide to (a) gradually
transition their legacy code bases to allow more checking, or (b) decide
that the checking is not worth it *for their particular code base*.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss