[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: os.setenv()???
- From: Rici Lake <lua@...>
- Date: Sun, 8 Jan 2006 14:04:37 -0500
On 8-Jan-06, at 1:21 PM, Ryanne Thomas Dolan wrote:
Also, the standard interface should be absolutely as thin as possible.
In that case, we should ditch io.lines(), right? And abandon the
abstraction of various dynamic loading interfaces into loadlib()?
Lua is a lightweight language. There are a number of ways of
interpreting that; one is as you suggest, make the interfaces as thin
as possible. The other one is to make the interfaces as simple as
possible. I'd personally opt for the latter.
Rather than providing a table as an abstraction of getenv and setenv
(as Rici proposes), the standard interface should define a one-to-one
mapping from Lua functions to C functions such as getenv, setenv,
putenv, and ChangeEnvironmentVariableToString (or whatever C functions
implement the desired task). If a function isn't provided by the
current OS, then the function is left undefined in the environment.
That's another possible approach; leaving the function undefined is
also quite a reasonable approach. However, I don't see the point of the
following:
local function resolve_setenv ()
if std.setenv then
return std.setenv;
elseif std.putenv then
return std.putenv;
elsif std.ChangeEnvironmentVariableToString
return std.ChangeEnvironmentVariableToString;
else
error ("std.setenv/putenv/ChangeEnvironmentVariableToString
is not implemented in this environment");
end;
end;
If you have to include that in order to portably setenv, then it might
as well be part of the library implementation. If you prefer that the
signal of non-implementation be that the function not be defined, then
you can achieve the same effect with a simple:
os.setenv("key", "value")
which will throw an error if os.setenv is undefined. (Or you could
pretest.)
Writing a standard library that morphs based on the OS is extremely
hard or impossible to write.
In the case of GUIs, yes. In the case of setenv, no. :)
The only common denominator is C 89, which Lua already implements
decently.
There are others. APR, for example, provides a cross-platform
implementation of a large subset of Posix facilities; presumably, it
was not easy to write, but it exists (and with a liberal open source
licence).
A one-to-one mapping is the only way to safely provide system
dependent functionality to all platforms. Anything else will only be
portable to a finite set of OS, which is not acceptable.
That seems like an odd statement to me. A one-to-one mapping provides
system-dependent functionality for the platform for which the mapping
is written. It is portable only by abstraction. Whether that
abstraction is done at the Lua level or in the context of a standard
library interface is simply a design option, but the use of the
language is certainly simpler if it is done through a standard library
interface. (Of course, the existence of the standard interface does not
actually mandate its use in a given project. You are certainly free to
implement alternative dynamic loading facilities, for example, which
could be a one-to-one mapping with, say, Netware NLMs. However, they're
not going to be as easy to integrate with the Lua 5.1 package
mechanism.)
For example, if some OS provides ChangeEnvironmentVariableToNumber in
addition to ...ToString, this functionality is not lost in the
standard.
Not at all. The (hypothetical) standard says that setenv(string,
string) does something and returns true, or does nothing and returns
nil and an error message. It does not say what setenv(string, number)
does, although it would be nice if it obeyed the same general outline.
If a given OS provided ChangeEnvironmentVariableToRGBAColor, then the
standard provides a strong hint as to how to implement that. The result
would be a Lua environment which was predictable.
- References:
- os.setenv()???, Chris Marrin
- Re: os.setenv()???, Luiz Henrique de Figueiredo
- Re: os.setenv()???, David Burgess
- RE: os.setenv()???, Dolan, Ryanne Thomas (UMR-Student)
- Re: os.setenv()???, David Burgess
- Re: os.setenv()???, Diego Nehab
- Re: os.setenv()???, Ryanne Thomas Dolan
- Re: os.setenv()???, David Burgess
- Re: os.setenv()???, Chris Marrin
- Re: os.setenv()???, Rici Lake
- Re: os.setenv()???, Ryanne Thomas Dolan