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