> 1) a project should use one distinct top-level package. In > particular, avoid clashing with an existing project's namespace. > > -But luasocket defines the less-than-elegant module ltn12 on the > top-level, which is a standalone helper
I consider LuaSocket as an example of what *not* to do when writing "modern" Lua modules. It is not only a design issue, see https://gist.github.com/3803669 for instance. ltn12 could probably just be a separate module, it is not so tied to luasocket, it defines a generic interface for I/O. > -sometimes it makes sense to add to an existing namespace - e.g > LuaExpatUtils adds lxp.doc. I don't like this kind of thing. Actually I think a module should never touch the global namespace, even to define a reference to itself. What I mean is that foo.lua should never do `foo = {...}`, and you should never write a line such as `require "foo"`. If you really want foo to be global write `foo = require "foo"`, but more probably you want `local foo = require "foo"`. If you do that you *cannot* patch another module, and this is a good thing. If you really want to write a module that messes with another module, make it explicit by returning a function that takes that module as an argument, e.g.: local foo = require "foo" (require "fooutils")(foo) -- patch foo The only exception to that I find OK is modules that patch _G directly, for instance pl.strict. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ Luarocks-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/luarocks-developers
