Refactor to submodules?

[jw3]

Thinking about #21, the packaging would be simpler if this project had been submodule based (as usual).

I'm thinking about a quick refactor that shouldn't be too disruptive.

1. Refactor in separate branch, rebasing on master
2. When ready to merge do a verbal check or schedule a time to eliminate uncommited changes (over the weekend?)
3. Final rebase and push to master

A branch for the packaging effort can be based off of the submodule branch, so it wont get held up waiting for a final merge of this.

Current submodules

• Standalone ScalaFX debugger
• DAPodil

[jw3]

... food for thought at this point, just wanted to throw it out there. I'm just starting to package up a release to use in the extension, so whether there is any advantage to splitting things out will soon be clear.

[arosien]

I generally avoid the ZIO stack, because of (reasons), and also I'm much more familiar with the Typelevel stack (Cats Effect, fs2, etc.). Most of the ZIO stuff in the ScalaFX debugger could be trivially ported--ZIO -> IO, ZStream -> fs2--except the ZLayers part, which I find to be a solution to a self-inflicted problem (of not "just" passing dependencies as arguments).

[jw3]

I'd like to keep the ZIO stuff around as an example (example-* repo), but see from the DAPodil stuff how it is a pretty straightforward port. It would be interesting to me as a learning exercise, but don't have the cycles right now.

Porting things aside, packaging the DAP backend should be separate from the other stuff, imo. So its either package from this single project and exclude things based on path, or package per submodule.

Or just ignore it and publish everything in here... which is likely a good enough approach to start out with.