Mash#disable_warnings with `CannotDisableMashWarnings` guard on base class is annoying

[nonnenmacher]

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

1. inconvenient when using yaml references 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.

2. 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 ?

[BobbyMcWho]

I've done some work in #488 that should solve most of your named concerns. It'll allow anonymous inline subclassing of Hashie::Mash using syntax like Hashie::Mash.quiet.new({ your: 'hash' }.

Since it's an inline anonymous subclass, you can also use it for your Mash loading of config files Hashie::Mash.quiet.load(...).

Faraday middleware already supports passing in a custom mash class so once this change is released, you'll be able to do something like.

connection = Faraday.new 'http://example.com/api' do |conn|
  conn.request :oauth2, 'TOKEN'
  conn.request :json

  conn.response :xml,  :content_type => /\bxml$/
  conn.response :json, :content_type => /\bjson$/
  conn.response :mashify, :mash_class => Hashie::Mash.quiet

  conn.adapter Faraday.default_adapter
end

The reason we shied away from allowing to disable mash warnings globally is that if a gem does this, it'll affect the consuming application and we do not want that to happen.

[nonnenmacher]

@BobbyMcWho sound very nice for me and solve both issues (see comment on #488).

[dblock]

Closed via #488