ModuleImport

Andreas Rossberg rossberg at google.com
Mon Jun 30 10:35:33 PDT 2014


On 30 June 2014 19:01, C. Scott Ananian <ecmascript at cscott.net> wrote:
> On Mon, Jun 30, 2014 at 7:14 AM, Andreas Rossberg <rossberg at google.com>
> wrote:
>>
>> > ...this is why I've been arguing strongly for consistent syntax
>> > regardless.
>> > 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
> them internally.

I don't understand what you mean by "lazy-bound" references. In any
case, the problem exists independent of circular module dependencies.

> 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.

I don't follow this line of reasoning. The language should define
clearly what a module is, what you can expect from it, and it should
do so consistently. Making it fuzzy and unreliable will just bite
everybody, especially since modules will define the boundaries between
code developed by different parties. If that's dogmatic then call me
that.

/Andreas


More information about the es-discuss mailing list