Re: Suggestion: Lua 5.3 -- a facility for creating and manipulting Lua file handles (C API)

I've felt a bit ridiculous trying to mirror some of the C structs when "exporting" them to Lua as tables, but I wanted people to be able to follow along with a C socket tutorial and expect the same member fields. Mostly I've been kept up nights about the tables I return from my getaddrinfo(). I really have to keep myself from molding it into a friendlier table, but why I am unhappy with luasocket is because I have so much trouble figuring out what to expect from its functions. The documentation only goes so far...

check out my monstrocity: https://github.com/Pogs/lsock/blob/master/lsock.c#L1560

On Sat, Nov 16, 2013 at 11:21 AM, Justin Cormack <justin@specialbusservice.com> wrote:

On Sat, Nov 16, 2013 at 5:31 AM, Andrew Starks <andrew.starks@trms.com> wrote:

>> The main focus of my socket bindings is that I was trying to be as true to
>> the C prototype as possible so it would be easy for beginners to take a C
>> networking tutorial and translate it to Lua without much guessing or digging
>> through documentation. Sometimes I feel like details about luasocket are
>> hard to find...
>>
>> I like your socket option code in net.c though, it's much friendlier than
>> what I tried to do by adding every defined CONSTANT I could and having a
>> get/setsockopt(). That's the only part of my code I really am not happy
>> with yet. I still need to get it to compile in Visual Studio, though...
>>
>
> This paragraph got me really excited. Well... not excited. It's more
> that I feel your pain.
>
> My solution, after trying the "every option * getter * setter" path,
> was to make an option struct that mixed and matched a small handful of
> functions. Some functions were "0 == true, everything else is an int",
> some were "-1 is false, everything else is an it" and one was "error
> and tell them that this property is read only." Then the rest of the
> struct held the property name, the default value, the void * to the
> property and the sizeof.
>
> I can say that, compared to Lua, it looks like poop with cheese on it.
> Compared to your average C code, it looks pretty tightly designed, but
> without all of the neat #define hacks that make C code look truly
> confounding.

These API design things are difficult. I have another socket
implementation (and other stuff) in ljsyscall
https://github.com/justincormack/ljsyscall and because it covers a lot
of stuff I have spent quite a lot of time trying to make things
consistent (and then changing my mind). The things with bizarre
interfaces like setsockopt, fcntl, ioctl and so on I have decided just
need special handling. I have got furthest with that and ioctl() which
now knows whether ioctls are read or write and what types are returned
so the amount of confusion and boilerplate is now pretty minimal as it
is all hidden away in the implementation.

So you can do things like fd:setsockopt("socket", "passcred", true)
for example, but there is still a lot of work to do to cover all the
use cases. I have block/nonblock as functions as fcntl is still on the
TODO list to clean up.

I don't see any substitute for documenting the Lua, and will start
soon. I have tried to use cross language docs before and they are
horrible really unless you are incredibly familiar with the source
language.

Justin