\o/ it works!
I’ve made a POC to change (on demand!) the implementation used by the stdlib when manipulating the system (OS) environment (through
Sorry in advance, it’s midnight here, and I need to sleeep!!..
(Also, even though there are a lot of code that can be generated, I didn’t do it yet to keep it clear)
The basic idea is to override the methods in
Crystal::System::Env (used by the stdlib) and
use a different implementation (impl) for these methods on demand, using
The exemple starts with the OS backend (the normal impl), then change the impl used to an in-memory env (you can set/unset/get without changing the OS env), use it then change back the the OS impl.
PluggableSystem::Env is the controller, that you use to choose which implementation to use for
Crystal::System::Env. It should be quite generic and could be done for all
Crystal::System::* system modules…
The applications are pretty cool I think, like in-memory / overlays file system, env, time, whatever…
I think it should be possible to control (and spec!) stdin/out/err without doing dark magic linux fd reopening…
AND if the
PluggableSystem concept is shared by muliple shards, or even integrated in the stdlib (in the future), we could have an abstraction over the OS to be able to do all sort of things (middleware?)
Let me know if you have any idea on how this could be used, or if you have suggestions, anything ;)
Time to sleep! I think I’ll continue working on this, and maybe make a shard or two (to isolate
It’s nice to do some crystal again See ya!