Re: modules, require, magic

[Sam Roberts <vieuxtech@...>]

On Sun, Oct 23, 2011 at 1:03 AM, Mark Hamburg <mark@grubmah.com> wrote:
>> 4. It adds the module to the global namespace. This, in my opinion, is a bad thing because it creates hidden dependencies -- i.e., code can use a module that it never required simply because some other code required it earlier and it became available in the global namespace.
>
> The problem here is that if module "foo" does a require "bar" which does a require "baz" and then module "foo" does a require "bleen", then bleen can see bar and baz without ever requiring them:

>        foo
>                require "bar"
>                        require "baz"
>                require "bleen"
>                        -- bar and baz are now visible to bleen

This is a way to create bugs, but I can't see it as a very big
problem. There are way better ways to code difficult and perplexing
bugs, in any language.

What happens is someone removes the require baz, the next time the
code runs, something in bleen errors out, with a message about trying
to index global baz. You look at the code, it does indeed use the baz
module, but didn't require it. Bad coder, no cookie! You then put the
require into the module definition.

How often can a bug like this actually suck significant
trouble-shooting time? Compared to the time to type require"logging"
into the top of every lua file in your code base?

I actually started using a lint tool for python, because it doesn't
have a way to make libs like logging globally available across an
entire app, you have to import it everywhere you use it. (actually, it
probably does have a way to do this, but would involve doing things to
the core that would be frowned upon by pythonistas everywhere)

I got tired of integration tests failing because I'd put calls to
logging.debug() in some code, and forget to add the import, so for the
first time ever with a dynamic language, I found a lint tool and
started using it. I feel its a failing in python that I'd not like lua
to repeat. And its sucked valuable time from me, our integration tests
take a long time to run and get back to us with a "you forgot to
import logging, try again" message.

And its worth noting that this can only happen to people who don't
unit test, any unit test like

-- bleen-test
  require"bleen"
  bleen.do_something()

would fail if blaz or any other dependency of bleen hadn't been
required by bleen.

>> 5. It mucks with the environment to make it "easy" to export functions. But then to compensate for this, it offers package.seeall which results in a module that reveals a lot of globals in its table which have nothing to do with the module -- i.e., it pollutes the API for the module.
>
> Bascially, the issues here has to do with whether it bothers one that if module foo uses the module function with package.seeall then references such as foo.print and foo.pairs and foo.math.sin are all valid.

Its odd, even ugly, but its also invisible if you do for k,v in
pairs(a_mod) do print(k,v) end. You have to
be pretty perverse to go looking for these things, and start to use
a_mod.io instead of io. Most people would never even know about this
side effect if they didn't think about it deeply, or hear somebody
else bring it up.

Cheers,
Sam