[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANNOUNCE]: LuaSocket 2.0.3 RC2
- From: Jerome Vuarand <jerome.vuarand@...>
- Date: Wed, 4 Nov 2009 11:33:54 +0100
2009/11/3 Diego Nehab <diego@tecgraf.puc-rio.br>:
> I agree getfd and setfd are not greatly thought out
> features. That's why I call them hacks and that's why they
> are not part of the documented API. They are there just for
> debugging purposes and for people who want to use them at
> their own risk.
>
> The problem is that these functions can lead to confusion on
> Windows, since socket objects are not file descriptors
> Having them in the API would seem to indicate it is ok to
> obtain a file descriptor from a file handle and then insert
> them in a socket object. This would not work on Windows and
> I don't like the idea of having this on the API.
>
> Now, if what we are talking about functionality that allows
> you to obtain this OS-dependent socket handle/descriptor and
> create another LuaSocket object from it, we can discuss what
> is the best API for it. It is a valid scenario that I had
> not foreseen, and I'd be happy to add it to the library.
I couldn't agree more. Leaking low level concepts in a high level API
is likely to make it non-portable. Lua userdata bing opaque to Lua
scripts is what makes it easy to nicely integrate any low level
mechanism or paradigm into Lua, even though it makes their
serialization impossible (but not all objects hidden behind a userdata
are naturally serializable anyway).