Re: Best way to pass options to a module at require time?

["Robert G. Jakabosky" <bobby@...>]

On Thursday 10, Benoit Germain wrote:
> 2011/3/10 Tony Finch <dot@dotat.at>
> 
> > The reason for this is that require() can be called any number of times
> > for the same module and when it is called the second and subsequent times
> > it just returns the existing instance of the module.
> > 
> > Tony.
> > 
> > The same applies to a
> 
> require "lanes".init(n)
> 
> idiom.
> 
> If I changed Lanes for this to become the 'standard' way of initializing
> Lanes, then it could be encountered more than once with different
> parameters. The only difference is that when used, this idiom guarantees
> that the init function gets called everytime the module is required, and
> not only the first time, which offers a means of complaining if different
> parameters are passed. In the case of Lanes, it happens that this
> parameter only serves to improve performance, but has no effect on
> available functionality, so it isn't that important. On the other hand,
> the above idiom has the drawback of the init call being mandatory: I can
> complete initializations and make the module usable only after the init
> parameter has been provided. In other words, forgetting to call the init
> function will leave the module in an unusable state, which would not the
> case if the parameter were forwarded by the call to require.
> 
> Benoit.

Would it be possible to wrap the module's state in a context object which is 
returned by the module's init() function?  Then all module functions that work 
on that shared state would be turned into methods of the context object.

This is what the ZeroMQ libraries does [1].  You create a common context 
object which is shared with all threads in a process.  The context object also 
creates a pool of IO threads that handle the IO work for ZeroMQ sockets.

1. https://github.com/iamaleksey/lua-zmq/blob/master/API.md

-- 
Robert G. Jakabosky