[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Problems with lposix on win32
- From: Rici Lake <lua@...>
- Date: Sun, 15 Jan 2006 21:32:39 -0500
On 15-Jan-06, at 7:25 PM, Chris Marrin wrote:
Since Lua has multiple return values, why not just always return errno
as the second return value of each (relevant) call?
Fair enough. In that case, errno() is unnecessary (and not obviously
implementable on non Posix systems).
POSIX (and Win32) standardize the names of the errno constants; I agree
that these should be strings (just simple strings, like "ENOENT"; the
WSA_ prefix can be deleted, for example, so that the names coincide.
There's a errno translation mechanism in APR which you could
stealxxxxrepurpose :) in general, I think looking at APR's API is a
good idea because a lot of people have thought hard about how to make
an API which is both portable and easy to use.
Just to explain my reasoning:
In order for functions which might be used as iterators to be usable as
iterators, it is important that they return <false, error>, rather than
<nil, error>. However, having thought about this a bit, and tried both
interfaces, I actually remain convinced that being able to access
errors "after the fact" leads to simpler code. It is certainly possible
to write:
for in, errmsg in f:lines() do
if errmsg then
-- handle the error
end
-- handle the non-error case
end
but it requires every script to think about the possibility of errors
in order to avoid a runtime type error (boolean used where a string is
required.) Maybe that's not a bad thing, but in many cases it is
actually ok to just let a loop die if an error is encountered.
Furthermore, errmsg in the above is local to the for loop, which is
also a trifle awkward.
I would rather not globalize the discussion into existing
functionality. I just want to get some needed functions online ASAP!
Good point. Sorry. I'll try and focus my thoughts about filesystem
interfaces for some other thread. :)
- References:
- Problems with lposix on win32, Chris Marrin
- Re: Problems with lposix on win32, Wim Couwenberg
- Re: Problems with lposix on win32, Ryanne Thomas Dolan
- Re: Problems with lposix on win32, Wim Couwenberg
- Re: Problems with lposix on win32, Rici Lake
- Re: Problems with lposix on win32, D Burgess
- Re: Problems with lposix on win32, Chris Marrin
- Re: Problems with lposix on win32, D Burgess
- Re: Problems with lposix on win32, Chris Marrin
- Re: Problems with lposix on win32, D Burgess
- Re: Problems with lposix on win32, Edgar Toernig
- Re: Problems with lposix on win32, Chris Marrin
- Re: Problems with lposix on win32, Rici Lake
- Re: Problems with lposix on win32, Chris Marrin