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
Object#in? #8671
Comments
EDIT: Sorry, it's not actually an alias. |
I don't know about adding something like this to the root object but it would be nice to have |
@Blacksmoke16 Yeah, it's true that it isn't technically an alias, but I think the principle is the same: it merely provides an alternative to something the language already supports. Probably not a good idea. |
I actually don't mind this, I've written I'm pretty ambivalent, if others in the core team are open im happy to accept a PR. |
@RX14 Sorry, should I go ahead and reopen this? Not sure what the proper etiquette is. |
@Marzipanzerfaust usually it ends up better to leave it a few days to make sure everyone's had their say before closing. |
@RX14 When used with a fixed set of values, |
Note that you'll need parentheses because the parser will think it's a block |
Is the only advantage to write an expression the other way around? Having two redundant methods will produce different styles: those who prefer I thought adding methods to There is also |
@straight-shoota yeah, a def in?(*values)
self.in? values
end would be neat |
Aliases on the same object (different names for the same method) are similar but different to shortcuts on other objects. This is on the borderline of breaking the no-aliases rule, which is why i'm open to the rest of the core team's input instead of rejecting it. |
My reasoning for this was similar to the existence of |
In any case, the |
Maybe this is redundant, but I have always thought that a Python-ish
obj.in?(enum)
would be more intuitive than the Ruby-ishenum.includes?(obj)
:The text was updated successfully, but these errors were encountered: