lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Diego Nehab wrote:

The package proposal allows for a lot of freedom. This is because Lua is
used embeded in applications that might have especial needs.

But does suggests the standard way of writing a package. This is with
the use of the module() function.  This function has a very well
specified behaviour. If your package uses module() (and it should use
it), then both

    local foo = require"foo"
    a =


    a =

will work. That's it. This is true of all libraries that don't try to be
creative by not using module().

That sounds good. I think library writers (as all programmers, and oh what the hell everyone) are basically lazy. If there is an easy way to do something they will use it. That's great because it means consistency will be the easy thing to do. Of couse, some library writers will have to be shamed into updating their libraries to use module :-)

Looking at the implementation of module it looks like it actually does place the module name in the global namespace. But that seems problematic for the reason mentioned here before. If I <<require "a">> then <<require "b">>, if "a" requires "c" and then "b" requires something different called "c" (because it fiddled with the path and looked someplace different), now "a" is using the wrong "c", right? Or am I missing something about how setfenv() works? I admit that I am having trouble understanding how setfenv() helps setting up an environment for an entire module when you just set it on a single function.

The proposal also specifies search order and search locations for all
types of libraries. It also specifies how to override many details that
can be specific to your deployment platform, doing so in such a way that
will make other people's libraries work in your system anyways.

At the moment, we are in transition. In the future, all libraries should
be be consistent. Please consider using the package proposal, as it will
make everyone's life easier in the long run.

Yes, it is a very good step toward consistency!

If there is anything you would like to be able to do when you package
your libraries, but feel you can't do with our proposal, this is the
right venue to talk about it. Chances are we can figure out how to do it
so that everything is compatible.

Thanks for the help so far. My big issues still have to do with isolating namespaces. For instance, what about the problem I mention above? Are modules required by "b" isolated from those required in "a", like they are in Python? Also, has anyone made a proposal for how you can promote all the members of "a" into the namespace of the module that requires "a"?

Thanks again...

chris marrin              ,""$, "As a general rule,don't solve puzzles        b`    $  that open portals to Hell" ,,.
        ,.`           ,b`    ,`                            , 1$'
     ,|`             mP    ,`                              :$$'     ,mm
   ,b"              b"   ,`            ,mm      m$$    ,m         ,`P$$
  m$`             ,b`  .` ,mm        ,'|$P   ,|"1$`  ,b$P       ,`  :$1
 b$`             ,$: :,`` |$$      ,`   $$` ,|` ,$$,,`"$$     .`    :$|
b$|            _m$`,:`    :$1   ,`     ,$Pm|`    `    :$$,..;"'     |$:
P$b,      _;b$$b$1"       |$$ ,`      ,$$"             ``'          $$
 ```"```'"    `"`         `""`        ""`                          ,P`