lua-users home
lua-l archive

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


On 18 August 2010 19:51, Lorenzo Donati <lorenzodonatibz@interfree.it> wrote:
> Roberto Ierusalimschy wrote:
>>>
>>> But, until then, for me the main issue is to understand most of the
>>> implications of my approach, i.e. writing a module with basic Lua
>>> syntax, with clean, linear structure and no special support from
>>> custom external functions (no "safe_require", "safe_module" or
>>> similar).
>>> And whether that kind of module could be robust, efficient, well
>>> encapsulated, generally applicable, with no pitfalls (or with
>>> well-known ones!), i.e "simple and foolproof", even if a bit verbose
>>> (compared with other approaches like yours, which rely on an
>>> additional framework).
>>
>> I would say that now the "endorsed by the Lua team" way to write
>> modules is like this: using clean and basic Lua syntax.
>>
>> -- Roberto
>>
>>
> Thanks Roberto!
> I'm glad to hear that my approach of writing modules is not simply a "poor
> newbie's" way to avoid too much conceptual load! :-)
>
> Well if that will be the "endorsed standard", it becomes still more
> important for me to get feedback on my specific way of doing that (potential
> problems, limits, etc.).
>
> On a related note, may I assume from what you said that now the standard
> contract for a module can be (incompletely) summarized as in the following
> lines?
>
> 1. when loaded and called, a module's chunk should return a table containing
> its "exported" symbols
> 2. a module should not create any global
> 3. ? any more items in the contract?
>
> (BTW should this contract be the same for both Lua and C modules?)
>

Without wanting to speak for Roberto, I don't think you can ask
questions like these. Lua always aims to let you as the developer
decide on any "contracts" you want to impose. Decide what fits best
for your application, and use that. Still as you'll know if you've
been following the list, there are simple "best practices" (not
necessarily specific to Lua), one of which is to avoid globals if you
can help it - but that doesn't mean you can't or shouldn't if your
desired design is best implemented this way.

The module() (and luaL_register) function in 5.1 is bad precisely
because it doesn't allow for this flexibility - i.e. it creates
globals whether you want it to or not.

So now it is quite simple... what the module returns will be the
return value of require, what you return is up to you, whether you
create globals is up to you, whether you assign to _ENV or simply
create a new table is up to you, whether you add anything else to the
"contract" is also up to you. Lua does not dictate things like this.

Regards,
Matthew