Reading the Ruby Source to Understand Rails Idiosyncrasies

http://pivotallabs.com/reading-the-ruby-source/

by cmdrcoriander • 13 years ago

58 24 13 years ago

ahawkins• 13 years ago

One uses a loop and one doesn't? Not sure if there's so much to get out of this post.

norswap3• 13 years ago

`cover?` uses the comparison operators to check if the value is within the range. `include?`, on the other hand, will behave like `cover?` only if the range values are "numeric". If they aren't, it will iterate through the range to see if it contains the value. This is possible because range values are required to implement the `succ` method which gives the next value.

RyanZAG• 13 years ago

If there's only one thing I've learnt from trying different languages out: the less magic, the better.

tptacek3• 13 years ago

This is an easy and thus superficial bit of insight to add. A more reliable truism would be that "unnecessary magic is bad", but that brings us no closer to evaluating Rails. Ultimately, you have to be able to point to specific magical behaviors and make a case for what makes them gratuitous.

ExpiredLink• 13 years ago

What is necessary magic?

majormajor• 13 years ago

Without turning this into a debate about particular bits of magic, my general conclusion from using Rails (especially when projects are in maintenance mode) is that it frequently makes it overly complicated to do things differently than how the framework wants you to, making you resort to monkey patching and other magical strategies of your own.

It's wonderful for prototyping but I'm becoming increasingly wary of it for production systems that are going to have a long life (at which point the whole perf/scaling thing comes into play too).

Which is all a very roundabout way of saying "use the right tool for the right job," I suppose.

james_madison• 13 years ago

how about Ruby with less magic? http://rubyluwak.com/

rdouble• 13 years ago

I vastly prefer magic, so long as it works.

jshen• 13 years ago

Define magic.

klibertp• 13 years ago

Well, sufficiently advanced technology, wasn't it?

fuzzix• 13 years ago

Indeed - the KISS principle was once commonly cited in this industry.

nicholassmith• 13 years ago

Magic is great, it's hugely entertaining and can be used for great effect. However, knowing how to deconstruct the magic is also very useful so you know how the sleight of hand has taken place.

danso• 13 years ago

Well, I learned about the cover? Method, so that's a big plus for a typical Saturday...but I'm confused as to why include? for ranges doesn't just act as an alias for cover?

I can't think of a Range that is not meant to be continuous...I would test out some cases right now if my computer weren't grinding away at a database insertion process...

edit: OK, tried it out....as I suspected, Ranges that consists of Strings will have different behavior:

    [16] pry(main)> ('aa'..'zz').include?('c')
    => false
    [17] pry(main)> ('aa'..'zz').cover?('c')
    => true
    [18] pry(main)> ('aa'..'zz').include?('cc')
    => true
    [19] pry(main)> ('aa'..'zz').cover?('cc')
    => true
    [20] pry(main)> ('aa'..'zz').cover?('cccccc')

norswap3• 13 years ago

Ranges are always continuous, but `cover?` uses the comparison operators, while `include?` iterates over the items in the range in some cases. `include?` is practical in cases where you don't want to implement the comparison operators.

See https://news.ycombinator.com/item?id=6076608

norswap3• 13 years ago

I was going to write that this was a failing of the Ruby documentation. But actually, it's pretty well documented if you take the time to read it (http://ruby-doc.org/core-2.0/Range.html).

There's absolutely no need to go hitchhiking in the C source in this case.

stormbrew• 13 years ago

While I agree that it's documented well enough that once you hit the situation and read the doc you should be able to figure out why without diving into the C, I think the documentation still fails in the sense that it doesn't give you any guidance as to why or when you would choose which one.

That said, I really don't consider this magic as another subthread suggests. include? just has an optimization for numeric ranges, but otherwise behaves exactly as Enumerable#include? should.

Denzel• 13 years ago

Well, first of all, you aren't reading the Ruby source to understand Rails' idiosyncrasies, you're reading the Ruby source to understand Ruby's idiosyncrasies applied to Rails.

Secondly, this article is far more verbose than necessary when compared to the succinct 5-paragraph explanation provided by David Flanagan in "The Ruby Programming Language" p. 69-70 [1]

It's great that you took a chance to dive into the source of Ruby. Nonetheless, it's times like these when I wish people would understand that the best way to learn a programming language is by example AND by documentation (whether official docs or books). Those that ONLY learn by example fail to understand or unlock the true power of a language until it's too late.

[1] http://www.amazon.com/Ruby-Programming-Language-David-Flanag...

zhoutong• 13 years ago

I wonder if looking up the source is really necessary. I did some tests with Rails console just now. It seems that Ruby and Rails are handling the case quite logically.

"3.days.ago" at least by default is a TimeWithZone object in Rails.

  3.days.ago.class
   => ActiveSupport::TimeWithZone

And then the way Ruby iterates Range is through the "succ" method. So even this will give you a wall of errors:

  (3.days.ago..2.days.ago).to_a

Sending "succ" to a TimeWithZone object will print a warning because the method is deprecated. So basically a warning will show for every second in the range.

Calling .include? should be equivalent to .to_a.include? in effect.

Reading the Ruby Source to Understand Rails Idiosyncrasies

Related Stories