Hey, there. Let me briefly talk about why I am using dry-initializer over dry-struct, first, before launching into what I am proposing.
I’ve stumbled upon these libraries two days ago, and I’m already really enjoying the prospect of dumping activemodel and all of my associated custom metaprogramming for the dry-rb family. I’ve already built up a few POCs to prove these libraries’ worth to myself and eventually my team.
I ended up adding lazily evaluated default values to activemodel, with some metaprogramming. I get this out of the box in with dry-initializer - and because you use instance_exec like I was doing myself, I can refer to other fields in my model. Great.
Really, my issue now is, I would like to avoid repeating myself when I start using dry-validation, and try to base my contracts on the same initial schemas for my objects - which seems like it would have been simple enough had I been using dry-struct. But, not with dry-initializer.
I would like to avoid writing to additional DSL wrappers for dry-initializer to “synthesize” and record my object’s schema to build upon for later dry-validation usage, but that seems like it is my smartest option.
My question is:
Have we thought about adding an “extension” to dry-initializer that would record the compatible portions of
option arguments as a schema? Even just the names and types? It seems like it would be very easy to do. And it would make for better interoperability with dry-initializer.
Side note, I really like your support for the arity==2 type procs in dry-initializer. Very handy for automatically setting references to a parent model.