lua-users home
lua-l archive

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

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 package.loaders?

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?

Ignacio Burgueño