Re: Overdoing 'local' (Was: [ANN] luaposix 33.4.0 released)

[Sean Conner <sean@...>]

It was thus said that the Great Dirk Laurie once stated:
> 2016-02-28 1:02 GMT+02:00 Sean Conner <sean@conman.org>:
> > 2) But it does mean that when I'm doing a heavy POSIX program, it's a lot
> > of:
> >
> >         local process = require "org.conman.process" -- fork(), etc
> >         local signal  = require "org.conman.signal"  -- signals
> >         local getopt  = require "org.conman.getopt"  -- parse command line
> >         local syslog  = require "org.conman.syslog"  -- syslog
> >         local errno   = require "org.conman.errno"   -- defines for errors
> >         local fsys    = require "org.conman.fsys"    -- file system calls
> >         local net     = require "org.conman.net"     -- network code
> >         local sys     = require "org.conman.sys"     -- um ... [2]
> 
> This can obviously be done in a loop, or by a single function call
>     import"process signal getopt syslog errno fsys net sys"
>  if you did not 'local' all those names. After all, you are probably
> going to follow all that with `local fork = process.fork` etc for the
> particular functions you actually need.

  Oddly enough, I don't do the 'local fork = process.fork' at all.  Here's a
pretty representation portion of the code [1]:

      socket:close()
      fsys.dup(connection:fd(),fsys.STDIN)
      fsys.dup(connection:fd(),fsys.STDOUT)
      io.stdin:setvbuf('no')
      io.stdout:setvbuf('no')
      connection:close()
      signal.default('child')
      local okay,msg = pcall(handler.main,remote)
      syslog('error',"handle_request = %s",msg)
      process.exit(process.EXIT.SOFTWARE) -- handle_request() should exit 

As to why I don't to the 'local fork = process.fork' bit ... it just doesn't
seem right to me.  Stylistic choice to be sure, but as I was writing this, I
wasn't sure what functions I would be using out of each module (and no, I
did not just use a bunch of modules, but as I needed a function from each
one, I would require it).  

> I wonder if the dogma of "Don't pollute the global namespace"
> is not being clung to too religiously. In this sort of situation, where
> the names are those of near-standard libraries (at least within
> conman.org), I think there is something to be said for keeping them
> in _ENV.

  Yes, but the program I wrote consists of a main application and three
additional modules, two of which also load up various org.conman modules of
their own (I should note that this is all Lua 5.1, but your point with _ENV
still stands).  This is less a speed optimization and more a "controlled
chaos" type of thing.  I've found that the less global variables I have, the
easier it is to reason about the code (and that's regardless of language).

  -spc (And by now I completely *loathe* Unix signals but that's a rant for
	another time ... )

[1]	gopher://boston.conman.org/1Gopher:Src:	[2]

[2]	Yes, that is indeed, a Gopher URL.  Yes, it is live.  I was inspried
	by MetaFilter starting their gopher server back up, and wrote my own
	to serve up my blog [3] via gopher.

	The gopher protocol is not a hard protocol to support.

[3]	http://boston.conman.org/