Rationale for dropping ModuleImport syntax?

[Matthew Robb]

I agree unless the properties of said object are getter-objects that return
the bound identifier from the exporting module. Of course this would
require specifying such a thing and can happen later.

What if we get rid of this "module instance object" and instead treat it as
a binding namespace? The engine would then bind the import based on the
accessed export.

    import  a from "b"; a.c;

Is the same as

    import {c} from "b";
On Jun 12, 2014 5:38 PM, "Calvin Metcalf" <calvin.metcalf at gmail.com> wrote:

> The fact that here is a distinction between the bindings from the module
> and the instance object of the module is the issue
> On Jun 12, 2014 8:30 PM, "Kevin Smith" <zenparsing at gmail.com> wrote:
>
>> So I think this argues for two actions:
>>
>> 1.  Leave the syntax as-is.  The "module from" syntax makes the
>> distinction between getting the module instance object, and importing
>> bindings from a module very clear.
>>
>> 2.  Educate.  Perhaps those of us on the list that really get modules
>> should be writing about them as well.
>>
>>
>>
>> On Thu, Jun 12, 2014 at 5:18 PM, Brian Di Palma <offler at gmail.com> wrote:
>>
>>> On Thu, Jun 12, 2014 at 10:07 PM, Calvin Metcalf
>>> <calvin.metcalf at gmail.com> wrote:
>>> > isn't the foot gun the difference between single and multiple exports,
>>> i.e.
>>>
>>> I thought it was imports that were being misused. People were writing
>>>
>>> module m from 'mymodule';
>>>
>>> m();
>>>
>>> So they treated `module` just like `import`. I'm not sure I see the
>>> logic in doing that.
>>> Did they not wonder why there were two ways to accomplish the exact same
>>> thing?
>>> As I said, I didn't find the reasoning compelling.
>>>
>>> > to import underscore you'd use
>>> >
>>> >     module _ from 'underscore'
>>> >
>>> > because it is multiple methods on an object but for jquery you'd have
>>> to use
>>> >
>>> > import $ from 'jquery'
>>> >
>>> > because the root object is a function instead of an object
>>> >
>>> > On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith <zenparsing at gmail.com>
>>> wrote:
>>> >>
>>> >>>
>>> >>> I was more wondering if there was anything preventing a module import
>>> >>> statement from being added later, if it was found to be a
>>> requirement.
>>> >>> I can't see any reason why it couldn't, that would also allow time
>>> for
>>> >>> bikeshedding the syntax.
>>> >>
>>> >>
>>> >> It could be added later, but to turn the question around:  why should
>>> it
>>> >> be
>>> >> dropped?  It has been part of the design for a very long time, it's
>>> >> currently used by many people working in the ES6 space, and it meets a
>>> >> semantic need.
>>> >>
>>> >> If you want to drop a feature this late in the game, then you need to
>>> show
>>> >> that it's one of the following:
>>> >>
>>> >> 1. Buggy
>>> >> 2. A footgun
>>> >> 3. Not useful
>>> >> 4. Future-hostile
>>> >>
>>> >> I don't see that it meets any of those requirements, do you?
>>> >
>>> > I have no strong opinions either way. I don't feel it's any of those
>>> things.
>>> >
>>> > The argument that was given was that people were confused by it and
>>> > were using it like an `import` statement.
>>> > I said to Eric via Twitter that if people were building incorrect
>>> > compilers and modules then they will eventually learn the error of
>>> > their assumptions.
>>> >
>>> > To me the argument didn't seem that strong, the native implementations
>>> > will be correct and people will correct their broken code.
>>> >
>>> > I'm not supporting the removal. I simply don't think it's a
>>> catastrophe.
>>> >
>>> >>
>>> >> Kevin
>>> > _______________________________________________
>>> > es-discuss mailing list
>>> > es-discuss at mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140612/120bd8b3/attachment.html>