ModuleImport

John Barton johnjbarton at google.com
Mon Jun 30 07:27:54 PDT 2014


Let me try to restate my request for clear information on the advantages of
module bindings vs module object architectures.

The import syntax already allows pre-execution tools to collect every
module that will be accessed by a root dependent module (including some
that may not be used).  This advantage is clear and it can be weighed
against the disadvantages, including more syntax restrictions to learn and
the need for a separate dynamic API.  On balance I think it's a win,
because I understand the advantage.

What's not clear is the advantage of module bindings form for modules.
 When the world of possibilities opens up, what specific things will I see
there?


On Sun, Jun 29, 2014 at 7:46 PM, Kevin Smith <zenparsing at gmail.com> wrote:

> Bruno and John's arguments are classic examples of the straw man fallacy.
>  In my concrete examples I made no reference to static type systems (or any
> type systems at all, for that matter).  I merely pointed out that by
> allowing the programmer to provide compile-time information in the form of
> exports and declarative forms, a world of possibilities opens up.
>
> Of course, static information can always be *inferred* from dynamic.
>  That's basically how JS engines work, but raising that up to some ideal
> principle is foolish dogmatism.
>
> They accuse me of advocating decades-old technology, but it is purely
> dynamic JS that is decades old.  "Evolve or die" is the way.  The "we don't
> need no stinkin' classes" argument is counter-productive, counter-intuitive
> reactionary garbage, and quite frankly it bores me.
>
> : P
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140630/3ab1cb63/attachment.html>


More information about the es-discuss mailing list