Re: Conceptual problem with module

[Mark Hamburg <mhamburg@...>]

on 4/26/06 1:45 AM, Grosch Franz-Josef (CR/AEA3-Fr) * at
Franz-Josef.Grosch@de.bosch.com wrote:

> My point of view is: A module is a globally unique unit. As soon as it
> is loaded (by require, preloaded or predefined) is has a globally unique
> name. 

The problem with putting modules into the global namespace isn't collisions,
it's that it hides dependencies.

If you have to write:

    local foo = require "foo"

in order to access functions in the foo namespace, your program will be more
robust against changes than if you use the global variable foo which just
happens to be defined because you wrote:

    require "baz"

And the process of loading baz just happened to load foo.

Now, you may say "But I wouldn't rely on that behavior of baz" and of course
you wouldn't. Intentionally. The problem is that it becomes too easy to
start using foo and not even realize that you haven't done a require on it
because you don't get an error.

Do you check that you've included every header file you need when writing C
code or do you let the compiler check it for you? If the latter, then
indirect inclusions are compile errors waiting to happen.

Having require extend the global namespace is a runtime error waiting to
happen.

And as for consistency with the standard libraries, one should probably have
to use require to get them as well.

The counterpoint to this tirade against adding things to the global
namespace is that the needs in a scripting context and particularly an
interactive context are different from the needs in a program development
context.

Mark