Why is twiddle wakka designed like this? - ruby

In the twiddle wakka ~> (aka pessimistic operator), why is it designed so that the tidle comes before the inequality? Since it includes the meaning >=, it is more consistent if it were >~. The ~> order makes it difficult to remember, and I often mistype it >~. It also makes me feel incorrectly that ~> 3.2 does not allow exactly 3.2. Is there a precursor to this symbol, or was it made up by a gem developer? Can someone come up with a way to make sense of this (even if that is not the original intention)?

Jim Weirich originally added the pessimistic operator to RubyGems as >* in this commit. He then changed it to ~> a few weeks later - the commit message includes an explanation:
Changed the pessimistic operator to "~>" (think approximately greater than).
Personally, I like that ~> is visually distinct from >=; if the operator was >~ instead, I think it would be easier to misread as >= when glancing at a Gemfile.

Related

Ruby Float#round behaviour change after update

I am upgrading a repository from Ruby version 2.3.3 to 2.5.1. A test is failing, and I have narrowed down the cause to the following behaviour:
In version 2.3.3
1.34875.round(4)
=> 1.3487
In version 2.5.1
1.34875.round(4)
=> 1.3488
Now, I'm aware of this change, but I don't think it's relevant because a) the default behaviour was left alone, and b) the observed change is opposite to the proposed change in the default. I'm also aware that floating point numbers are not a good way to accurately store finite decimals, and that some change in precision might explain why this change has occurred. But I don't know, and I don't know how to find out.
The behaviour you're describing sounds like https://bugs.ruby-lang.org/issues/13138, which was considered a bugfix and backported to 2.3.5. (I haven't confirmed which 2.4.x it was backported to, if any, but it was in trunk before 2.5.0.)
As you surmised, it is a precision issue. 1.34875's float representation is slightly less than 1.34875, so 2.3.3 does the overly-technically-correct thing and rounds down; newer versions recognise that rounding up is more consistent given that the float actually represents a range of values [including 1.34875].
The default behavior was not "left alone" as you suggest. There's new strategy to round to nearest even number: https://github.com/ruby/ruby/blob/8d7c380216809ba5bd4a3eec41d7dda61f825ffa/NEWS#core-classes-updates-outstanding-ones-only (search for round).
You can use
> 1.34875.round(4, half: :down)
=> 1.3487
To preserve what seems to be the behavior in 2.3.3.

Did Ruby deprecate the wrong File exists method?

The docs of File.exist? says:
Return true if the named file exists.
Note that last word used; "exists". This is correct. "File exist" without the ending s is not correct.
The method File.exists? exists, but they deprecated this method. I am thinking it should have been the other way around. What am I missing?
Also, it's noteworthy that other languages/libraries use exists, for example Java and .NET.
Similarly, "this equals that" - but Ruby uses equal, again dropping the ending s. I am getting a feeling that Ruby is actively walking in another direction than mainstream. But then there has to be a reason?
This is largely a subjective call. Do you read the call as "Does this file exist?" or "File exists"? Both readings have their merits.
Historically Ruby has had a lot of aliased methods like size vs. length, but lately it seems like the core team is trying to focus on singular, consistent conventions that apply more broadly.
You'd have to look closely at the conversations on the internal mailing list surrounding the decisions here. I can't find them easily, only people dealing with the changes as deprecation warnings pop up.
The Ruby core team is a mix of people who speak different languages but the native language is Japanese, so perhaps that's guiding some of these decisions. It could be a preference to avoid odd inflections on verbs.
I agree that if File.exists?('x.txt') reads much more natural than the plural form, which was probably Matz's intention for the alias. As far as I'm concerned, this particular deprecation was misguided.
However the general preference of a plural form may well be routed in handling enumarables/collections, where plural makes a sense when used with idioms like this:
pathnames.select(&:exist?)
exist? matches the convention used elsewhere throughout the stdlib, and goes back to the early days of ruby. For example array.include? (not includes?), string.match? (not matches?), object.respond_to? (not responds_to?). So in this light, File.exists? was always a blemish.
Some recommend that you read the dot as "does". So "if file does exist," "if array does include," "if string does match," etc.

Why does this Regex time out?

This might not be the ideal question for Stackoverflow, sorry if I really violated a guideline (like "Too localized". But this is quite an interesting problem:
I have the following Regex (a simpler version of URL matching):
\A(http(s)?:\/\/)?(([\da-z\.-]+)\.([a-z]{2,6})(\.([a-z]{2,6}))?([\/\w \.-]*)*\/?)\z
Now if I test this string (which doesn't match, because of the special characters):
http://t3n.de/news/nokia-lumia-930-test-560264/?utm_source=feedburner+t3n+News+12.000er&utm_medium=feed&utm_campaign=Feed%3A+aktuell%2Ffeeds%2Frss+%28t3n+News%29
Like this (just to make sure I didn't make an obvious error):
str = 'http://t3n.de/news/nokia-lumia-930-test-560264/?utm_source=feedburner+t3n+News+12.000er&utm_medium=feed&utm_campaign=Feed%3A+aktuell%2Ffeeds%2Frss+%28t3n+News%29'
str.match /\A(http(s)?:\/\/)?(([\da-z\.-]+)\.([a-z]{2,6})(\.([a-z]{2,6}))?([\/\w \.-]*)*\/?)\z/i
The command just runs forever. Shouldn't it return nil since the string doesn't match? I use the latest version of ruby, but this also occurs on Rubular: http://rubular.com/r/2ajABaqmTE
jarvis:~ rudolf$ ruby -v
ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-darwin13.0]
Any ideas what might cause this? Did I discover a Ruby bug or what am I missing?
Inside your regex, there's this:
([\/\w \.-]*)*
which causes the regex engine to create a lot of states that it can possibly backtrack to. You can safely remove the last *:
([\/\w \.-]*)
The way I see it, the 2nd * in this part ([\/\w \.-]*)* is redundant and causes great amounts of backtracking. Remove it and it works fine: ([\/\w \.-]*)
You have a lot of capture groups and you might want to remove them as well if you don't intend to use them, but that won't have as big of an impact.

Does Set in Ruby always preserve insertion order?

i.e., is Ruby's Set equivalent to Java's LinkedHashSet?
In Ruby 1.9: yes. In Ruby 1.8: probably not.
Set uses a Hash internally; and since hashes are insertion-ordered in 1.9, you're good to go!
As mu is too short points out, this is an implementation detail and could change in the future (though unlikely). Thankfully, the current implementation of Set is pure ruby, and could be adapted into an OrderedSet in the future if you like

Do ruby gems ever conflict?

As a ruby newbie, I was wondering, will gems ever conflict with eachother? For example, if 2 gems overrode the << method on array, which would win, or is there something to stop this?
Thanks
I assume you are talking about redefining methods, not overriding them, right? If two libraries overrode the same method in two different subclasses, there wouldn't be any problem.
If two or more libraries redefine the same method, then whichever one happens to be loaded last wins. In fact, this is actually no different than just one library redefining a method: the Ruby interpreter provides an implementation of Array#<< for you, and if you redefine it, your definition wins, simply because it came later.
The best way to stop this is simple: don't run around screwing with existing methods. And don't use libraries that do. The -w commandline flag to enable warnings is very helpful there, since at least in Ruby 1.9.2 it prints a warning if methods get redefined.
In Ruby 2.0, there will probably be some kind of mechanism to isolate method (re-)definitions into some kind of namespace. I wouldn't hold my breath, though: these so-called selector namespaces have been talked about in the Ruby community for almost 10 years now, and in the Smalltalk community even longer than that, and AFAIK nobody has ever produced a working implementation or even a working design for Ruby. A newer idea is the idea of Classboxes.
As far as I can tell, you're talking about monkeypatching (also known as duck punching in the ruby community).
This article has another example of monkeypatching (and other practices) gone bad.
In practice, no, though you could probably construct a situation like that if you really tried. Here's an interesting article (though old) that explains how this could happen.
If two gems "overrode the << method on array" they would need to be subclassing Array, and those classes would have different names or be in different modules.

Resources