lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Rici Lake wrote:
A few things:

On 15-Jan-06, at 12:43 PM, Chris Marrin wrote:

The original lposix package had this, but it had a third 'overwrite' param. I don't think this is needed, since you can see if a variable exists with os.getenv() and then avoid calling osex.setenv() if so.

setenv with overwrite (should be) atomic, which you cannot achieve with getenv/setenv. However, I don't think anyone actually uses this feature as a locking mechanism, so I don't see any need to reproduce it.

I didn't think about that "feature". But I agree that it is overkill.

Given that, it seems like a table interface to getenv/setenv is much more natural than a function call interface. Moreover, it's faster. It also makes it easy for a sandbox to provide a fake environment. So personally, I'd prefer to scrap both getenv and setenv, and just provide an os[ex].env table.

That sounds fine to me. But for now I would just implement it internally as calls to getenv() and putenv() and let the community deal with "protecting" it with a private environment. Also, unless an installation chooses to take it away, the standard os package will still have a getenv().

Almost all of your remaining functions have to do with the filesystem, not the operating system; the exceptions are sleep() and possibly errno(). I think sleep() is uncontroversial; the remaining filesystem-related calls should go into a filesystem library, not an os library (imho).

It's interesting that you would say sleep() is uncontroversial since even it has detractors. Such is the way of a concensus library, I suppose!

errno() is very difficult to use from a scripting language...

On the whole, I think that errors should be retained with OS-like objects, which is essentially the semantics of standard C i/o, for example, where each FILE has its own error indicator (which can be both read and cleared.) That would be possible to implement, and I think it would be easier to implement that in an OS-independent way. In addition, it would be easier to use. Say, for example, that both files and sockets had a lasterror() method (or a lasterror key). That would make it much easier to write loops which respected error conditions:

  for line in f:lines() do
  if f:lasterror() then   -- or possibly "if not f.eof"
    ... report the error

Since Lua has multiple return values, why not just always return errno as the second return value of each (relevant) call?

I personally think that open() should be a member function on a directory object, rather than a global. An implementation should provide both a root directory object (sort of the analogy to stdin) and (if possible) a cwd() function; regardless, there would be some object onto which open() errors could be attached. This would simplify programming of directory traversal functions as well.

I would rather not globalize the discussion into existing functionality. I just want to get some needed functions online ASAP!

chris marrin              ,""$, "As a general rule,don't solve puzzles        b`    $  that open portals to Hell" ,,.
        ,.`           ,b`    ,`                            , 1$'
     ,|`             mP    ,`                              :$$'     ,mm
   ,b"              b"   ,`            ,mm      m$$    ,m         ,`P$$
  m$`             ,b`  .` ,mm        ,'|$P   ,|"1$`  ,b$P       ,`  :$1
 b$`             ,$: :,`` |$$      ,`   $$` ,|` ,$$,,`"$$     .`    :$|
b$|            _m$`,:`    :$1   ,`     ,$Pm|`    `    :$$,..;"'     |$:
P$b,      _;b$$b$1"       |$$ ,`      ,$$"             ``'          $$
 ```"```'"    `"`         `""`        ""`                          ,P`