lua-users home
lua-l archive

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


Hi,

Diego wrote:
> [...] The user calls
>     mime = require"mime"
> 
> [...] In mime.lua [...]
>     local mime = requirelib("mime")
> 
> The implementor *knows* which is which. Why eliminate this freedom?
> I disagree with Mike Pall on this.

Sorry, maybe I haven't made myself clear enough. I was worried about the
*user* having to know which kind of library he/she is loading. I was not
talking about the coder of the library! So in fact we agree on this point.

In my first mail I was saying:
: A way to load either a Lua or a C library with a single function.        
: The function should internally use _LOADED, require() and loadlib()
: and take care of platform specific issues.

This was referring to the *user* of the library. I was not talking about
whether a core mechanism or a stub mechanism takes care of loading the
proper library type.

The Python example I gave was just showing _one_ approach (all in the core).
And after some tracing I showed that it's probably not such a good idea
to follow this example (excessive path lookups).

Sorry for the confusion. So, just to make it clear:
- I want *one* function for the *user* of a library (your example: require).
- I'm in favour of always using Lua stubs to reduce unnecessary path
  lookups.
- Of course the coder of the stub then needs a *different* way to load
  the C library (your example: requirelib).

However what should not happen is that some clever coders of a library
start to use requirelib for importing foreign libraries because they
'know' it's just a stub. That should be explicitly discouraged.

The Python precedent also shows that many C libraries grow additional
functions over time. And quite a few of them are not written in C.
So sooner or later you will need a stub anyway.

BTW: The name 'requirelib' may be a bit misleading for a newcomer.
He/she might assume that this is the proper way to load a 'library'.
The same could be said about 'loadlib' but it's too late to complain
about that. Maybe someone finds a better name, but this is really not
such a big issue.

Bye,
     Mike