arsd users: weigh in on proposed breaking change

[Adam D Ruppe]

On Friday, 23 December 2022 at 07:55:31 UTC, Greggor wrote:
> But I do not pull in the full arsd repo & I'd hate to see that 
> to become a requirement. In general I love the "its just a few 
> files you can add" to dependency management, but I don't mind 
> it becoming a couple of files.

Yeah, there's some temptation to break out a few more 
interfaces... well, ok i admit it is more than just some 
temptation, there's actually four or five files I'd probably add 
if there was zero concern (I'd do the eventloop+error 
handling+validation helper core, then a circular buffer 
container, the text layouter, and then possibly a couple more)...

but I think I'll resist that and just put a set of things in the 
one additional core.d file, that compromise I think will do what 
I need it to do. The others in the list aren't as important.

And of course, it is possible to keep doing things how I do it 
now, with some duck-typed interfaces that happen to be compatible 
if you pass the right arguments, then I copy/paste what needs to 
be pasted. But that's getting a bit limiting since i don't copy 
*everything*.

> As for event loop stuff, there is a golden rule in my eyes, as 
> long as there is a way to own the loop, just call a 
> poll/dispatch function and I can still use the thread, there 
> should be no issue with it.


eeeeeh, you shouldn't have to! but yeah, if you look at my 
http2.d current thing that's the model I've been coming to like. 
There's an `advance` function, a `addToSimpledisplayEventLoop` 
function which offers a file descriptor to integrate with an 
external thing, then the individual tasks can `waitForCompletion` 
and such.

then, of course, you do have a static `runEventLoop` kind of 
thing to just drop and run.

So you get some control but it might be a lot of extra work 
depending on what you're doing around it. Whereas if you make use 
of the event model you ought not need to do other stuff in the 
middle; you might even run the events in a separate thread and 
just queue messages back to this one.

I haven't worked out the exact details yet but I'm fairly happy 
with how that http2.d thing has worked out api-wise, and the 
simpledisplay core is pretty solid allowing for integrations, so 
I'll probably just generalize those.

Either way, yes, I do try to keep things decomposable so you can 
mix and match what you want. It might be a lil extra work for 
both of us but p sure I can keep it working for all these cases.

(and I plan to keep my existing apis forwarding to the new thing, 
to avoid code breakage, and this also forces me to do it in a 
flexible way since my own existing things will require some of it)