Re: as so often before require()

["Wim Couwenberg" <w.couwenberg@...>]

Hi,

> >  LTN 11 - Require revisited: Import, by Wim Couwenberg
> >  http://www.lua.org/notes/ltn011.html

Peter Hill:
> It makes reference to LTN7 (modularising by returning a table) which is
> something I just naturally do myself when using "dofile".

LTN7 does not mention _returning_ the interface as a table but instead gives
examples where a package plugs its global interface directly into the global
namespace.

> But, in the case of "packages", I wonder if that is appropriate?

Instead of directly returning a table, a "LTN11" package returns a
_function_, that installs the package in a given public table (as its first
argument.)  If a table is put directly into the global namespace, it should
at least be clear _where_ it ends up.  In Python for example an "import aap"
call will result in a global module at "aap."  Note that this can be easily
implemented with the LTN11 import call.

> ... it might simply be more appropriate to wrap their import with a global
> table and let them alter that? The "import" call would then return that
> table.
[... snip snip ...]
> In order to keep the cyclic access protection one would keep the 'stub'
> table mentioned by Wim but, instead of a returned definition function, one
> would also create a temporary global table to wrap the package execution
in.

The trouble is that packages will need some "common" globals like print (and
even probably import itself), etc.  I tried some scenario's but in the end
globals table manipulation didn't fit the bill.  You can easily restrict a
package's globals though by making this restriction just before the import
call.  The package will be run with the same globals as the import call
itself (sort of "inline.")

> After the package is fully executed the contents of the temporary global
> table would be copied into the stub, and the stub would be unlocked
(against
> cyclic accesses).

Import uses the stub as the actual public table for the package install and
returns it.  So, no copying...

> Whether using this method, or that of LTN11, the (currently undocumented)
> metamethods that prevent "get/setmetatable" should be used on the stub
> table.

I agree.  The same goes for the import function itself.  Because import
should be available to a package you must make sure that a package cannot
"steal" import's globals table!  However, setting the __globals field is a
non-local operation (it affects _all_ functions with the same globals
table.)  In the import script that you can find on my homepage I offer
import through a "function proxy" to literally cut off all globals.  A
simple but useful technique...  I will put the __metatable in there as well,
thanks.

> Rather than returning an error, "import" should probably store the
> metatable and enable it upon unlocking the stub.

?  Do you think you can handle more dependencies than the current proposal?
That would be worthwhile.  It's just that I don't understand your remark...

Bye,
Wim