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
    ...
  end
  if f:lasterror() then   -- or possibly "if not f.eof"
    ... report the error
  end
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
chris@marrin.com        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`