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 <zenpars...@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 > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
