Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

[Sean Conner <sean@...>]

It was thus said that the Great pocomane once stated:
> On Mon, Feb 3, 2020 at 10:39 AM Sean Conner wrote:
> > > The fact is that a file descriptor does multiple different things (it
> > > both controls the stream and provides the stream) so no name will be
> > > satisfactory.
> >
> >   I don't follow.  A file descriptor on POSIX is a integer value that has
> > ...
> 
> I meant that it is the same "Thing" to be passed to read, write,
> ioctl, fcntl, etc. So it serves a lot of purposes. If in your API you
> want to use a descriptive name (instead of _tofd), it will be a very
> generic and "Opaque" name.
> 
> >   I might have failed to fully describe the output from getting the events
> > list.  It doesn't return a set of *all* the event sources leaving the user
> > to scan through the list looking for ones with activity, it returns a list
> > *of only the sources that have activity during that call*.  If I set up
> > event monitoring for 10 sources and call set:events(), I might get back a
> > list of two events, but both those events have been triggered.
> 
> A loop over the returned events is still needed. And it becomes
> trickier if the event sources must be handled in a specific order. 

  Citation needed for handling in a specific order.

> I do understand that this is a very minor argumentation. But what do you
> think are the drawbacks of using the fd/source as key?

  With select() and poll(), the list of file descriptors is kept on the user
side; with epoll() and kqueue(), the list of file descriptors is kept on the
kernel side.  The effect is that epoll()/kqueue() return a list of file
descriptors that have events.  This is another reason I'm asking for a
citation for handling in a specific order.

> > > Sorry for the very raw state of my ideas.
> >
> >   So raw they seem like pure speculation and uncertainly about how this
> > stuff works.
> 
> I explicitely stated that I was putting down some idea, not making a
> practical proposal. I just described what I would like to see in a
> portable standard library: a notification system that can be extended
> to support different kind of events/sources.
> 
> I hoped that this kind of talks were welcome. Sorry again if I was wrong.

  Talks are welcome, but hypotheticals are tricky to deal with---they might
never actually be a concern.  I'd much rather have actual specific problems
with the current crop of event drivers.  As I'm reading your words, you come
across to me as someone who doesn't know that much about event driving
programming, especially with the comment about libuv being a generic event
handling library, when it just wraps the APIs I'm already talking about.

> > > - Object oriented programming
> >
> >   Why?
> 
> I think that a Standard Library /API should provide oop in order to be
> taken seriously. I know that constructors, inheritance, private data
> and so on can be implemented in 30 lines of lua. But the people just
> expect that a Standard Library /API has that 30 lines wired inside.

  I think we'll have to agree to disagree.  I think OOP has been oversold
and most of the examples used to teach it have done more harm and encourage
bad design.  Even Alan Kay, who is credited with coming up with OOP, said it
was a miskake on his part [1].

  -spc

[1]	Or that we as an industry failed to read his mind and failed to
	understand what he was actually trying to say.