Re: [CommonJS] Revisiting "include" (was: QUnit and CommonJS)

[Kris Kowal]

On Thu, Oct 8, 2009 at 12:18 AM, Hannes Wallnoefer <han...@gmail.com> wrote:
> Helma NG provides an include(x) that defines all properties exported
> by module x into the local module scope. It can do this because it
> works with pythonic aka top-level module scopes[1], which is a fully
> compatible extension to the securable module spec. I still think this
> wins head and shoulders over pure securable modules, and Helma NG code
> is so much cleaner for it.

This opens an old wound; it was amply discussed in January and I was
originally on the pro-include side of the debate with a large body of
code using it already. I agree that it's convenient; but I've been
convinced it's a bad idea for standardization because, we can frankly
live without it (We avoid the var F = r("f").F pattern almost entirely
in Narwhal by almost always using late binding on var f = r("f")), and
eventually we'll be able to use destructuring like var {F} = r("f")
which is about as convenient *and* safe. It's also become quite
obvious to me that while going from require to include would be easy,
it is *extraordinarily* difficult to do the reverse since information
about which free variables are in use and where they are from is
effectively lost. If that's difficult for the author of a body of
code, it's impossible for someone trying to learn how your code works.

Kris Kowal

[Kevin Dangoor]

FWIW, I think include is nice as an *extension* and, in my apps, I'd use it occasionally. There are rare times in Python where I use from something import *, and those are the same times I'd use include.

Destructuring will actually be a lot nicer... (and, assuming i'm using the right interpreter for my apps, I can use that today.)

Kevin

--
Kevin Dangoor

work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com

[Hannes Wallnoefer]

2009/10/8 Kevin Dangoor <dan...@gmail.com>:

That's what I thought, too. However, I find myself using it all the
time. I think it depends a lot on locality, size, and number of
modules you use. You also start function names that stand for
themselves, for example our fileupload module exports isFileUpload and
parseFileUpload, or our unit testing framework has assertion methods
like assertEquals etc.

I wouldn't want to use these with anything but include, except maybe
python's "from x import y". For completeness, I should als mention
that Helma NG has an import() that is equivalent to python's import.

> Destructuring will actually be a lot nicer... (and, assuming i'm using the
> right interpreter for my apps, I can use that today.)

We have object destructuring shorthand in NG, but I found it looks
really cramped for module imports.

Hannes