Re: Luasocket question.

[Diego Nehab <diego@...>]

Hi,

> I would add a few lines to the C source of luasocket.
> These would be of no consequence whatsoever to users
> who are not aware of the new feature.

You are underestimating the effect of unecessary changes. ;)
I would have to (at least) maintain it and document it.
Plus, there is the "precedent" effect. I am sure there are
simpler ways to solve most different issues. If I merge all
these specifics to the tree, a monster will soon be born.
That's why people (especially in this list) try to resist
changes.

> Maybe I'm just too Lua-illiterate for this. The description
> alone sounds horrible to me ;).

You think patching the distribution is better than this?

Allow me to explain again. When a socket userdata object is
created, all methods it defines are stored in the __index
field of a metatable. This is standard procedure in Lua
programming, and nothing especial about LuaSocket.  What is
peculiar about LuaSocket is the fact that these metatables
are stored the registry (see luaL_newmetatable), 
keyed by socket class name (tcp{client}, tcp{master},
tcp{server}), and are accessible to whoever has access to 
the lua_State (see the auxiliar.c in the distribution for
helper functions).

The only two functions that create a TCP socket userdata are
the global socket.tcp(), which is trivial to overload, and
the method accept(), which you can overload with my
suggestion above, by simply replacing the "accept" field
from the __index associated to the relevant socket classes
with your own (that does whatever additional book keeping
you want, before calling the original one). The same can be
done with the garbage collection method, which is the only
destruction point of sockets (you can overload method
close() too, if you want).

I suggested how to do it in Lua. You said you don't want to
do it in Lua. So now I suggested a way to do it in C.  It is
now up to you to convince me this is not a viable approach.

> I don't claim that the approach is the most elegant.
> It works with the minimum change to luasocket's C source.

I disagree. The approach I described potentially works with
*no* change to the LuaSocket C source. ;)

Regards,
Diego.