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

[pocomane <pocomane_7a@...>]

Sean, if you stopped to write the API specification due to this
discussion, please don't. Continue your remarkable work.

On Tue, Feb 4, 2020 at 6:08 PM Sean Conner wrote:
> > 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 have not.

> > 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.

Ok, no citation so just trash all the rest as proposal. But I would
ask you to answer to the following anyway, since there is something I
am missing, and I want to understand.

You reported how the data is returned from epoll/kqueue. After that,
you have to build the lua table from scratch, right? Why build a lua
table with fd/whatever as key is different from built a lua table with
the same fd/whatever in the array part?

> > > > 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,

It is partially true since I never "Provided" such systems (except a
very simple one based on select). But I use them every day (as library
user). And I always had to do one of the following:

1) Tie myself to complex frameworks that can handle different type of
events. As a real world example (lua-less, it was C), we worked on a
machine control that got inputs from tcp and electrical signals
(proprietary ADC/DAC board, we migrated to modbus only later).

2) Use a language that provide an ubiquitous competitive multi
threading mechanism. We wrote several rest services in Go. it is very
simple thanks to its thread model.

An extedable event system would be a third option (a sort of modular
variation of the first one).

> especially with the comment about libuv being a generic event
> handling library, when it just wraps the APIs I'm already talking about.

Sorry for the misunderstanding: libuv is not "Generic" or
"Extendable". However I think it is not just a "Select/epoll" wrapper
neither. At least this is what I found in its documentation: they use
some blocking IO through a thread pool [1].

Exposing this ability to external C modules, is what I call "Generic
and extendable event/notification system".

> > > > - 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.

And I have to disagree to agree to disagree. Yeee... to write this
sentence made my day. In short I agree with your view about oop:
probably, I should have added "in order to be taken seriously by
people (not me)".

But I still believe that oop should be in a standard library because a
lot of people REALLY want it, to the point to discard languages that
do not support it out of the box.

Moreover, providing a simple oop system into a standard library can
prevent the users to build complex solution when it is not needed.

---

[1] http://docs.libuv.org/en/v1.x/design.html at bottom of the page. I
did not read the libuv sources, I used it a little, I may have misread
something. However the rest I wrote would be the same since libuv was
not essential for the discussion.