arsd users: weigh in on proposed breaking change

[H. S. Teoh]

On Mon, Dec 19, 2022 at 09:56:37PM +0000, Adam D Ruppe via Digitalmars-d wrote:
[...]
> And that's something I still will continue to support - while I
> provide a little of everything, I try not to force you to buy into my
> worldview just to use a little bit. If you like my png.d but not my
> simpledisplay.d, that's ok, they work well together but they also work
> just fine independently. Or if you like my simpledisplay but prefer
> your own image formats lib, it shouldn't be too hard to make adapters
> for the interfaces since I still try to keep things decoupled.

In one of my projects, I actually used a subset of
arsd.terminal.Terminal's API as the basis for introspecting
terminal-like objects in the code. There are a bunch of generic
functions that use DbI to implement terminal-like functionality on
things like virtual screens, sub-screens, buffering screens, etc., and
of course Terminal itself.  One in particular is a function call capture
proxy that records calls to (a subset of) Terminal functions and saves
them to a file, that can later be played back by a separate program. The
playback can be to an instance of Terminal, or to another terminal-like
virtual screen that renders the playback into pixels using some
user-configured font and outputs an animated gif. :-D  All of these can
be more-or-less transparently swapped (and to a lesser extent Terminal
itself, because I was too lazy to implement DbI for all of its methods,
I just arbitrarily chose the subset I use the most), giving rise to all
sorts of cool tricks.

Your modules being more-or-less independent of each other was an
important factor in making this possible. If Terminal had, for example,
used some type defined by another module into its API, it would have
made these DbI adapters more klunky to write, because another
terminal-like wouldn't be able to define its own equivalent of that type
without running into potential conflicts.


> Just at the same time, having a common core to import that defines a
> few of these interfaces helps with that interop too, which is why I'm
> looking at this.

Makes sense, as long as core.d doesn't grow without bound. ;-)


T

-- 
Stop staring at me like that! It's offens... no, you'll hurt your eyes!