Mash#disable_warnings with `CannotDisableMashWarnings` guard on base class is annoying
nonnenmacher opened this issue · comments
OOPS sorry that was destined to Intridea.
My bad, shame_level ++
I read carefully #273, #243, #244
and proposal to simply subclass Mash to avoid this guard code
fail CannotDisableMashWarnings if self == Hashie::Mash
However there so many, commons cases, where subclassing to get access to subclass#disable_warnings is unpractical, PIA or just plain impossible.
let give some examples
-
inconvenient when using
yamlreferences to get better configuration.example
default: &default
:version: '0.1'
development: &dev
<<: *default
:myconfig: ...
lead to
WARN -- : You are setting a key that conflicts with a built-in method Hashie::Mash#default defined in Hash.
you can tell me, just go to ALL your yml configs and replace your default with a better name (curious what could be your proposal for a better default 'default' name ?)
if using Mash.load(...) in your configuration loading, you have to subclass every instance of such loading code with such config and that a real burden.
- PIA then using middleware that indirectly use Mash
e.g using Faraday Mashify middleware, that conveniently Hashify a Response (quite your example), how can you get access to this internal class ?
You're have to ask the middleware developer to have an option, to inject your own 'subclass'.
We have in production, a LOT of logs where we just consider ditching altogether Hashie::Mash for too much load/space... just because of those unavoidable
You are setting a key that conflicts with a built-in method Hashie::Mash#zip defined in Hash.
for all REST endpoints that are unfortunate enough to deal with ZIP_CODE for Person like entities.
you can tell me, to change every representation of such response to `zip_code`
even on endpoints that aren't in my realm ???
Conclusion
Allowing one, to take responsibility to call at load time something like
Hashie::Mash.disable_warnings
would be more nicer, for people in production that can't easily access/subclass/change things that lead to those unavoidable warnings.
Could this be reconsidered ?
@nonnenmacher Sorry for the late reply. First, what's the meaning of "PIA"?
And I understand that like the following...
"#273 was not a good way of suppressing the warning message."
...Right?
If you think "destined to Intridea" still now, just close this, please 😉
sorry for the glitch !