Re: Re[2]: import and LuaBinaryModules

[Thatcher Ulrich <tu@...>]

On Mar 07, 2003 at 10:34 +0800, Peter Hill wrote:
> Peter Hill:
> > Ah, but as far as:
> >     import "a.b.c"
> > goes the name clashs problem only occurs with *other modules*, which
> > can be handled by whatever module naming and/or versioning
> > convention may be decided upon.
> 
> Thatcher Ulrich:
> > Yes -- exactly!  The problem must be solved by packagers and module
> > maintainers.
> 
> I agree. Module identification (including version numbering) is a key issue
> to be resolved.
> 
> 
> >  Once the problem is solved there, it is solved for everybody; there is no
> > problem in Lua's global table, if the module names are unambiguous.
> 
> Not at all!
> 
> Just because the module names are unambiguous with each other does not mean
> they won't conflict with a user's global. Mixing the module naming
> convention in with general globals is just an (unnecessary) mess. Variable
> names (including globals) are by definition a programmer's choice, whereas
> module names must match a (yet to be specified) convention.

Yes, you're right, the onus is on the specification.  Currently the
luacheia proposal is to put everything inside the global table "lib".
So you might have "lib.SDL", "lib.pcre", "lib.socket", etc.  Probably
this will be hierarchical so you could have "lib.SDL.mixer",
"lib.SDL.ttf" etc, to organize a group of related modules.  The spec
is not nailed down yet though.

> And requiring that the module be assigned to a fixed global is just
> pointless! Any chunk of code that wishes to make use of a module should
> import it itself anyway (and there is no harm in doing so since once a
> module is loaded once that reference is reused) at which time it is free to
> choose how to name it for personal use. Each program unit makes its own
> choice. Eg:

I think it's actually very good to have a fixed global namespace for
modules -- it makes it easier to write "portable" library code, which
might get cut & pasted together with other code.  For example I think
it will be a very good benefit to know exactly what lib.socket.open()
means, without having to search for the module importing and aliasing
code.  It also makes code snippets much more generically readable, if
the programmer so desires.

The footprint in the global namespace is exactly one variable, "lib".
I agree aliases are nice for more localized code which isn't designed
to be shared, but I think that should be optional, rather than
requiring the programmer to make up arbitrary aliases for modules.

-- 
Thatcher Ulrich
http://tulrich.com