[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Packaging and importing
- From: Chris Marrin <chris@...>
- Date: Sun, 14 Aug 2005 08:33:44 -0700
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 = foo.bar(5)
a = foo.bar(5)
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
chris marrin ,""$, "As a general rule,don't solve puzzles
firstname.lastname@example.org 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`