Rationale for dropping ModuleImport syntax?
Brian Di Palma
offler at gmail.com
Thu Jun 12 14:18:31 PDT 2014
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';
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
>> 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.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss