Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rename rash? #9

Open
shishi opened this issue Apr 12, 2014 · 7 comments
Open

rename rash? #9

shishi opened this issue Apr 12, 2014 · 7 comments

Comments

@shishi
Copy link

shishi commented Apr 12, 2014

Hashie now have own Hashie::Rash.
https://github.com/intridea/hashie/blob/master/lib/hashie/rash.rb

So, I think rash have to rename other name. Or, we can not use rash with future version Hashie...
But Faraday Middleware use Rash, and there is already rash user.

It seem hashie rename their own rash is better?

@tcocca
Copy link
Owner

tcocca commented Jun 18, 2014

So, you are right, Hashie 2.1.0 added a Rash class. Any ideas for new names?

I think I will release a final minor version of Rash that has a hashie dependency of < 2.1.0

Then I will need to release a brand new gem with the new gem name.

Any thoughts?

@shishi
Copy link
Author

shishi commented Jun 19, 2014

Like suggested in lostisland/faraday_middleware#91, I suggest Rash into Hashie::Mash, not in Hashie. (Hashie::Mash::Rash)
I believe it express Rash inherit Mash, and is better than move namespace to global.

caseylang added a commit to caseylang/desk that referenced this issue Jul 30, 2014
Hashie duplicated the functionality of Rash in version 2.1.0. Using both
gems together causes a namespace collision. For more details see:
tcocca/rash#9
@pboling
Copy link

pboling commented Nov 30, 2015

It has been discussed in the Hashie project to move all the classes, including Rash, to mixins instead, such that Hashie would simply be a library of composables. If they were to do that, then the namespace collision might be resolved, though that may also be a ways off in the future.

@dblock
Copy link

dblock commented Dec 29, 2015

Rash is not going to be removed from Hashie and it serves a very different purpose (regexps). I've played with various options and I think the best short term idea is to rename Rash here to something else and call it a day. This way there would be a path forward for anyone using this gem.

More work would be to port the camelCase conversion as UnderscoreKeyExtension into Hashie and deprecate this gem altogether, telling people to use a different class (a hash with extensions).

@tcocca
Copy link
Owner

tcocca commented Dec 29, 2015

Hi guys, I'm not opposed to a rename, does anybody have any ideas? I can't remember the original reason I had called it rash but like @dblock said, they aren't removing it. Basically they whole point of my initial idea was to use underscored string names for hash keys instead of camel cased names when consuming the responses from APIs because I do not like typing things like 'keyName' and I like 'key_name' better.

So, basically, I have no problem porting the gem to a new name. Also, since it inherits from Mash, should we do it with a Hashie::Mash::{new name} scope? or still maintain Hashie::{new name}

I'm open to anything at this point.

@tcocca
Copy link
Owner

tcocca commented Dec 29, 2015

Also, my rash wouldn't be part of Hashie, that was pretty clear back when I originally made it hashie/hashie#7

@elyobo
Copy link

elyobo commented Dec 29, 2015

Keep the name Rash but use a different module name; the source of the problem was reusing the Hashie module name for your Rash in the first place. If you need to monkey patch something then you can't avoid that, but given that you're subclassing you don't need to do that and this is exactly the sort of problem that namespaces (modules in this case) are meant to avoid.

E.g. if you change to Tcocca::Rash instead then you won't have this problem again. Bump up a major version number so that people generally won't get caught out and it seems fine.

Edit: added example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants