[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Location of a package
- From: Ignacio Burgueño <ignaciob@...>
- Date: Fri, 22 Feb 2008 18:29:38 -0300
Roberto Ierusalimschy wrote:
'require' already decouples its process of finding a module, using
loaders. This new function package.searchpath will easy the task of
writing new loaders. (E.g., both the C loader and the Lua loader are
just calls to searchpath.)
Ok, so package.searchpath will return the location of the file. Since
I'm working on making the location available to the required modules, I
came across some issues that might be usefull to include in the discussion.
If a host environment wants to customize the way modules are required,
either it'll patch the 'require' function or use custom loaders. I
didn't want to patch 'require', so I went for the custom loader approach.
I wrote a loader that makes the location of the module available to the
module itself. I added it at the end of the loaders table, no problem there.
I also made another loader to customize the C loader. If I see that the
module 'foo' is required and I'm running on a debug environment, I'll
require 'foo_d' instead. But since 'foo' exports its entry point as
luaopen_foo, I have to use package.loadlib.
I want to place this loader to execute before Lua's native C loader, but
not before others. But how do I tell which is which by traversing
Should the loaders table be split into Lua and C loaders ?
Suppose the modules are not in the filesystem. Maybe embedded as
resources, in the host itself, into some library or somewhere else. In
that case, package.searchpath would be of no use. So, what about a
'searchers' table, that allows to add custom searchers there?