arsd users: weigh in on proposed breaking change

Adam D Ruppe destructionator at gmail.com
Mon Dec 19 13:27:37 UTC 2022


I've been thinking for a while to add a module `arsd.core` upon 
which the others can depend. This would have some interop 
definitions and implementation of the pieces necessary to make a 
shared event loop.

I also wrote most of a new text layout class over this weekend. 
My original intention was to embed it in simpledisplay.d since it 
was going to be tightly coupled to it and only useful with its 
draw text functions anyway.

However, after writing most of it, turns out it isn't actually 
coupled to simpledisplay at all, except for one font-related 
interface, which doesn't even have to work in terms of pixels! 
This means it could potentially be used by terminal.d as well and 
be the base of both character grid / tui and gui applications. 
The terminal.d ScrollbackBuffer *might* be able to use it (though 
since that thing already works as-is, idk if i would actually 
change it) and some of the terminal.d LineGetter could 
potentially be merged with a minigui LineEdit.

The benefits aren't exactly groundbreaking, but there's some 
potential here.

On the other hand, this would break the build for anyone who 
updates the individual files, since it'd change the import web.

I'd also have to shuffle some basic definitions like Point and 
Rectangle out of color.d and into core.d, which could affect 
static imports.

Before:
    terminal.d = stand-alone
    cgi.d = stand-alone
    http2.d = stand-alone
    color.d = stand-alone
    simpledisplay.d = needs color.d

etc. etc.

After, if we make all the changes:

    terminal.d = needs core.d, textlayouter.d
    cgi.d = needs core.d
    http2.d = needs core.d
    color.d = stand-alone
    simpledisplay.d = needs color.d, core.d, textlayouter.d

Anyone who downloads the individual files - which I've been 
telling people they can do for many years now - will have to get 
more of them and update their build process.

Moreover, the core event loop stuff might require you to actually 
run it in your thread, but I think I can do that right without 
breaking interop with outside systems anyway... and public 
imports can fixup reshuffled module members, so the main breakage 
here is for users who download the files.



So my question to those of you who use my libs... does this sound 
worth it to you? Of course, you can always just not update the 
file again, and stay happy with the version you have, but it 
seems likely that something will come up eventually that forces 
you to resync with me, so even though this breakage might not 
affect you today, I ask you to reply anyway since it might affect 
you tomorrow.

I expect I stress out too much over this, but I do try to take my 
promises of long-term support seriously and this is something 
that's worked without breakage for about 7 years now (which is 
where I added color.d and renamed the imports) so while it is 
small, I still don't want to break things without a real benefit.

PS if you do use my libs and wanna show off the project, please 
do! I'm always curious if people actually find these things 
useful.


More information about the Digitalmars-d mailing list