dgkf
Explore R6 for storing debugger state
As proposed by @sebffischer, R6 could be a good candidate for some of the internal state that gets passed around.
https://github.com/dgkf/debugadapter/blob/main/R/adapter.R#L22-L35
Of these, some are immutable and really don't need to be in a mutable state, but the capabilities, breakpoints and breakpoint_id would be candidates for R6 classes.
I'd be open to exploring an R6 class for either just breakpoints or the adapters/debuggers in their entirety. However, I'm inclined to still use a functional style preferentially, and only resort to R6's OO style when it fits particularly well - otherwise just using R6 for its mutable internal state.
Just as a small follow-up to this, I toyed around with S7 a bit, which strikes a more comfortable balance between OO and functional for my liking.
Personally, it still felt a bit clunky. Without multiple inheritence is R6 or traits in S7, I still feel like I'm often fighting the OO system. In most cases, I think I still prefer a little custom-built stateful data structure.
I'm not totally opposed so I'm keeping this door open, but for now I'm not convinced.
I've been re-thinking the model used for the adapter and revisiting my understanding of the specification.
With the simplification on the browser (no longer needing a "shadow browser"), the model becomes a lot simpler. We can move from a bit of a "chain" structure (client <-tcp:18711-> DAP <-tcp:18722-> REPL <-stdio-> shadow browser) to a "hub and spoke" model. (client <-tcp:18721-> DAP <-tcp:18721-> REPL).
Why all the details? Because it means that both the IDE client and the REPL "client" can be abstracted rather nicely. The REPL is a bit specialized in that it is the "debuggee" (providing R debug state) as well as a "client", but the types of clients are still more homogenous.
This means that we don't require such intense multiple dispatch. Now the adapter process hosts a server socket and each client can do a rather simple handshake with any client that wants to connect.
In this model, R6 becomes a much more attractive option. I've got a refactor that is feeling very promising that adopts R6 for the adapter and clients.