Live data from Hacker News

An 'in' operator for Ruby

rubyhacker.com

41–50 of 69 posts

Re: An 'in' operator for Ruby

#41
Could be worse, consider testing for inclusion in Javascript with Array#indexOf, where you don't even get a boolean value back.

The fact that the Ruby method is called include? and not includes? is annoying though.

Re: An 'in' operator for Ruby

#42
post #36

If it's this importing why not propose it: https://bugs.ruby-lang.org/ Ruby has a place for this sort of thing and they'll answer you.

It was proposed in 2010 and rejected by Matz in 2012: https://bugs.ruby-lang.org/issues/3845

something went wrong between

Matz: I am neutral for this proposal.

... ...

Matz: This proposal is only for cosmetics. I don't want a new operator that does not introduce something new.

[I personally disagree and think the 'in' operator should be added]

Re: An 'in' operator for Ruby

#43

Earlier quoted context omitted.

Agreed > if item not in collection reads quite nicely. I don't see what the problem is there? Anyway, I don't think his one gripe with this is enough reason to throw the rest of his argument out.

unless item in collection Obviously is the best choice

Touché ;)

Re: An 'in' operator for Ruby

#46

One day we will have a 'no-awkward'™ english like syntax: https://github.com/pannous/english-script

AppleScript tried to do just that:

https://en.wikipedia.org/wiki/AppleScript

It doesn't work out very well in practice. Inevitably the syntax diverges, and then it's pretty confusing for the novice user: why do some sentences work but most don't?

Re: An 'in' operator for Ruby

#47
post #37

I actually found it more interesting that Ruby hashmaps ("hashes" :S) preserve insertion order and guarantee predictable insertion. I was taught to never trust the ordering returned by iterating over keys of hashmaps because it can be a source of bugs as you move between architectures or interpreters. If you need a guaranteed ordering, keep (and pay for) the appropriate auxiliary data structure. Has this lesson becom…

It's a side effect of their implementation and you should continue to not trust their default ordering.

Re: An 'in' operator for Ruby

#48
post #47
post #37

I actually found it more interesting that Ruby hashmaps ("hashes" :S) preserve insertion order and guarantee predictable insertion. I was taught to never trust the ordering returned by iterating over keys of hashmaps because it can be a source of bugs as you move between architectures or interpreters. If you need a guaranteed ordering, keep (and pay for) the appropriate auxiliary data structure. Has this lesson becom…

It's a side effect of their implementation and you should continue to not trust their default ordering.

It appears that since Ruby 1.9 they guarantee insertion order: http://ruby-doc.org/core-2.3.0/Hash.html

I guess there are two approaches to solving the problem of people using your data structures the wrong way.

Edit: wrong link

Re: An 'in' operator for Ruby

#49
post #29

Earlier quoted context omitted.

I actually find that the use of "!" over "not" improves readability. English words tend to all blend together and take more time to parse, whereas a nice "!" token is easy to recognize at a glance. That being said, "not" is of course more understandable for somebody who has no idea about the language; however, asking a programmer to learn a single symbol for "not" is not too much to ask :)

depends how much attention you're paying at the moment. its easier to miss a ! than a 'not' at a quick glance

good point! all syntax highlighters should color negations in neon red

Re: An 'in' operator for Ruby

#50
post #46

One day we will have a 'no-awkward'™ english like syntax: https://github.com/pannous/english-script

AppleScript tried to do just that: https://en.wikipedia.org/wiki/AppleScript It doesn't work out very well in practice. Inevitably the syntax diverges, and then it's pretty confusing for the novice user: why do some sentences work but most don't?

from my experience Apple's problem with AppleScript was not so much diverging syntax but constant undebuggable crashes
Post reply on HN