Re: Packaging and importing

[Rici Lake <lua@...>]

On 16-Aug-05, at 5:25 PM, Diego Nehab wrote:

> > 3)  Drop the support for package return values, they're just confusing
>
> I don't like this idea. One might desire to write a package whose only
> exported symbol is a function. Returning that function works and is
> useful.

In fact, it's quite common in some styles. If I'm binding an "object" 
(with an object-oriented interface, that is), the only function I'm 
going to directly export to Lua is the constructor function. Everything 
else is accessed via obj:method() calls, and is therefore in the 
object's method table (however I might choose to implement that).

There's little point putting a single constructor function into a 
package just for the sake of having a package; I personally prefer to 
write, for example:

  local aThingie = Thingie(<constructor args>)

than

  local aThingie = thingie.new(<constructor args>)

but, of course, tastes differ.

Having said that, I could have achieved that effect, if desired:

  local Thingie = require"thingie".new

But I find the following somehow more satisfying:

  function new(name) return require(name) end

or, if that wasn't available:

  function new(name) return require(name).new end

either of which let me write:

  local aThingie = new "Thingie" (<constructor args>)

I might not actually do that, but I know people who would :)

All of this is predicated on 'require' not mucking with the globals 
table.