[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] luaposix 33.4.0 released
- From: "Gary V. Vaughan" <gary@...>
- Date: Sat, 27 Feb 2016 18:04:46 +0000
Hi Steve,
Thanks for the feedback :)
> On 27 Feb 2016, at 15:02, steve donovan <steve.j.donovan@gmail.com> wrote:
>
> On Sat, Feb 27, 2016 at 4:44 PM, Gary V. Vaughan <gary@vaughan.pe> wrote:
>> - posix.curses has been split back out into its own separate
>> project again.
>
> Gary, I think this is a good decision. Most Lua people on Unix-y
> systems need luaposix to interface with the system. Curses programming
> is entertaining, but a minority pursuit.
I thinks so too. Also, it allows the lcurses binding not to be constrained
by the POSIX curses API, so we can add ncurses mouse functions among others.
I’ve been on a simplify-and-separate binge of late, and have been wondering
whether luaposix is more useful as one giant library that tries to cover the
entire POSIX API, or whether it would be better to follow stdlib’s lead and
break it into multiple rocks along some (yet-to-be-determined) boundaries,
with a backwards compatibility luaposix rock that pulls in everything else?
It was surprising how much cruft I was able to eject by splitting up stdlib,
and making a clean break from supporting older versions of the API — and
luaposix is carrying many hundreds of lines of code to support deprecated
calls and types, so it would likely benefit even more.
I won’t get to it for some time, but I’d definitely be interested to hear
if anyone would shed a tear if I made some future release that similarly
made a clean break from supporting previous APIs?
Cheers,
Gary