Extract Trash behavior into an extension

[michaelherold]

Issue #188 brought up the fact that a Trash is really just a Dash with
some extended behavior. Why don't we make that a little more explicit
and define its behavior as an extension?

Follow Up

If this is merged, I move that we deprecate Trash for removal in 4.0.
I think reducing the number of classes will help users better understand
what behavior they are including in their subclasses.

In the long run, a 4.0 release would look really good with all of the behavior
factored out into extension methods. As we continue down that path, we can
slowly deprecate all of the *ash classes with the 3.x releases.

What do the other maintainers think of this suggestion?

Fixes #188

[dblock]

This is great, merging.

I wonder whether deprecating *ash classes will just make it harder on users, after-all they are "typical".

[dblock]

Before I merge ... this needs documentation for the new extension in README.

[michaelherold]

Whoops! Thanks for the reminder.

[michaelherold]

There we go, I added the docs to the readme.

Regarding deprecating the *ash classes:

My reasoning behind that suggestion is that the availability of the classes can lead to them being used in ways that aren't actually their intended use. Since I've been helping with Hashie I have heard the mantra that "*ash is [first and foremost] a Hash". I agree with this sentiment; we are going out of our way to ensure that the *ash classes are Hashes and no Hash functionality is removed.

However, because Hashie has these wonderful classes that automagically allow them to wrap a JSON response, often Hashie -- in particular Mash -- ends up being used in cases where it's not actually appropriate. The controversial blog post by Richard Schneeman -- along with the arguments on Reddit and in the OmniAuth repo -- shows an example of this. Another example is elasticsearch-rails, where Hashie is used to wrap all of the responses from Elasticsearch which causes issues in our application and caused us to want to either make Hashie optional or remove it as a dependency.

I feel that making people choose which extensions they want to use instead of giving the larger classes outright will help make them think more about what they are doing and help lead to using the right tool for the job.

That being said, I know that a lot of our users are using it in this way and have argued in the past that we should cater the ways Hashie is being used now. I'm of split minds on the issue, but I thought that a discussion around this extraction might be a good step for Hashie 4.

I believe that @gregory is in favor of extracting all behavior into mixins, based on comments in that discussion I linked earlier. I can't really speak for anyone else, but others might want to weigh in. I'm interested in your opinion, @dblock, since you raise the good point that it might just make things more difficult for users.

Is further feature extraction like this something we want to pursue? What about deprecating the *ash classes?

Also, should I move this discussion to a new issue?

[dblock]

I think you should open an issue about deprecating *ash classes, and we can talk it over there (copy-paste ^^^).

[gregory]

This is awesome @michaelherold !
And yes, i'm still convinced that it should be modules to include instead of a bundle of obscure and untraceable features wrapped into a class.