Introduce Dry::Core::Inspect

[pyromaniac]

Hello folks.

I'd like to share a little helper module that I'm using for some time already and find it convenient and worth being added to the Core and used everywhere (like, Dry::Struct, for example).

The usage is quite simple and very similar to Equalizer. In fact, in my code they are usually included together and with exactly same arguments.

Please let me know what you think of this idea.

Thanks!

[bkuhlmann]

ℹ️ This is interesting. I'm not a core maintainer but wanted to mention I've hit this same pain point and built Inspectable to solve this. I don't have built in pretty print support like you do but make it so you can use transformers with tons of possibilities for further customization on what is output.

[pyromaniac]

@bkuhlmann if this one is accepted - we can bring the best from both worlds. But first of all, do I understand it correctly that the only thing this one is missing from your one is transformers? If so, then frankly either I misunderstand the use-cases or it is fully covered by second argument here namely value_methods_map and the only difference is that your helpers are predefined and reusable. But then it is as simple as defining your reusable helpers wherever you want in PORO, no need for this additional complexity.
Please let me know if I'm missing something. Thanks!

[timriley]

Thank you, @pyromaniac! I've often wanted to reach for something like this, and I think it would be a great addition to dry-core.

I haven't checked the code yet but I will endeavour to do so soon.

In the meantime, I might ping @flash-gordon for his thoughts.

[bkuhlmann]

Arkadiy: Yeah, so there are several differences as Inspectable will account for whole value objects (i.e. Struct and Data) since they behave differently than standard classes. There are also preconfigured transformers for common issues like when Dry Schema dumps all over your screen or you need to filter out sensitive information. More importantly, you can add new transformers easily in order to account for different edge cases. So more flexibility. Lastly, you don't always need custom object inspection which is why it's nice to have a stand-alone gem for this.

Anyway, assuming that Boussier's Issue lands in Ruby core soon, much of what you are doing here goes away anyway.