Unless the language itself enforces the namespaces on modules, nothing
of this will really be effective. At most what we can get is a good
practices document. But since one can always write: function ns.a() t
= {} ... end (and now t is global) we can never be 100% sure one's
module will not interfere with the global namespace or other module's
namespace.And this behavior doesn't seem likely to get changed since it'is so deep in the concept of the language (not randomly, variables are global by default). Not even the functions in the standard library are protected (E.g.: next = 1, will work). This helps to keep the language simple, just as intented. So, I think that lua developers must somehow always count with this situation. So, having a formal recomendation to avoid writing a "init.lua" module is a good thing. Also, warning that your module polutes (or better, alters) other's namespaces is good (E.g. one might put a function in string table in order to have it available to OO syntax - a = " a ":trim()). But going much farther than this, IMO, does not make much sense. In the end, natural selection will make best modules live and the ugly ones die (unless they adapt themselves). --- Eric Chiesse 2013/1/22 steve donovan <[email protected]>: > On Tue, Jan 22, 2013 at 11:42 AM, Pierre Chapuis <[email protected]> wrote: >> ltn12 could probably just be a separate module, it is not so tied to >> luasocket, it defines a generic interface for I/O. > > This is true, but we must accept the world as it is... > > Personally I also don't like abuse of the global namespace since it is > so tricky to debug. It is not a bad thing that module() is dead. I > think module writers should be aware that modern Lua programmers > (especially those who work with big codebases) tend to be allergic to > globals. > > If I was to add another rule, it would be that require 'foo' should > never return `true`. That breaks the tidy assumption that 'local foo > = require "foo"' always works. Otherwise, people can implement > modules as they see fit, as long as they document their interfaces. > > I used to be too fond of global metatable hacks. E.g. overriding % > for strings to basically mean 'format'. I've been busy ripping this > kind of thing out in the search for pure code that cannot stand on > _anyone else's toes_. > >>> -sometimes it makes sense to add to an existing namespace - e.g >>> LuaExpatUtils adds lxp.doc. > > A clarification - this module did not modify lxp's behaviour in any > way, just provided some utilities, particularly a way to dump out LOM > structures to a string. So this is a lesser sin - putting a module > into some other project's namespace. (I don't think it even put a doc > subtype in the global lxp) > > steve d. > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
