Make code more readable.

[ream88]

I know, it is a ridiculous change, but it makes the code much more readable. 😃

[MSch]

I like it, but can you require 'active_support/core_ext/object/inclusion' on top?

[ream88]

Done!

[MSch]

Thanks @Haihappen!

[steveklabnik]

Ugh. I'm a big 👎 on this, not that it's my gem... we're actually not using in internally in Rails anymore, iirc... where was that ticket...

[ream88]

@steveklabnik really? Why exactly? It's so much better to read imho.

[MSch]

Well I agree that it's a lot easier to read, but if Rails stopped using it internally then that's a death sentence for in? in the long term (which in the rails world means 1 year) so I'd revert it.

In general I'm not that happy with many core exts in AS, but since ruby 2.0 will bring refinements (\o/) and since this gem will be used with Rails exclusively my thinking basically was to adhere to the Rails coding standards.

[steveklabnik]

I don't find it to be more readable. I recognize that this is taste.

It's also backwards from an OO perspective. You ask an array if something is in it, not something if it is in an array...

Anyway, yes, see this recent commit: rails/rails@447b6a4

[steveklabnik]

since ruby 2.0 will bring refinements (\o/)

:'( We apparently have very different tastes in Ruby.

[MSch]

IMO Refinements are a superior solution to open classes, because they require opt-in. That way the're kinda like scala's implicits conversions/parameters, which are nice because they'd let me use - say - the old meta_search DSL that monkeypathes (implict conversion/refinement) Symbol next to whatever else that doesn't expect Symbol#greater_than

Anyway, that commit is a good reason to revert. Sorry @Haihappen.

[ream88]

@MSch we should keep up with Rails Core team, so feel free to revert this commit!

@steveklabnik I should definitely read more Rails commits since Rails is a set of good practices. Will never use in? again 👅

[steveklabnik]

• Refinements don't solve the problem. The whole point of AS is to do a global monkeypatch, it's not like AS will use refinements. And they'll want to support Ruby 1.9 for a while, so they wouldn't get used for a few years anyway.
• Refinements are confusing. In what context do my strings have #foo again?
• Refinements are slow. They reduce the speed of all code by about 10% (iirc, it used to be 30%), even code that doesn't use refinements.
• Refinements make it hard for language implementors. The JRuby and Rubinius team have said that it's gonna make their lives really hard.
• Refinements aren't classboxes. I haven't had my coffee, so I don't remember why I'm saying this, but it's another Ruby thing that's sorta-kinda like the CS concept, but a little bit off...

This thread isn't about refinements, though, so it's super OT, just sayin'.

[jandudulski]

it's also backwards from an OO perspective. You ask an array if something is in it, not something if it is in an array...

agree