ModuleImport

Kevin Smith zenparsing at gmail.com
Fri Jun 27 12:47:34 PDT 2014


>
>
> >
> > The module author has the choice to re/structure his module to allow lazy
> > binding/checking *iff the users demand*.
>
> All this means is that there will effectively be two different module
> systems, and in practice, every module provider has to pick one. Which
> is a problem, not a solution.
>
>

Right - and this piles complexity on top of complexity, from both the
user's point of view and the implementer's/analyzer's point of view.  If
you're going to demand such complexity, then you at least have to back it
up with some real, concrete advantages.  What are they?  Bullet points are
good.  : )

Just so we agree what we're talking about, this is the default-default
solution, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140627/6ad07384/attachment.html>


More information about the es-discuss mailing list