

Yehuda Katz's 10 Favorite Things About Ruby  - wifelette
http://yehudakatz.com/2009/08/24/my-10-favorite-things-about-the-ruby-language/
"I work with Ruby every single day, and over time have come to really enjoy using it. Here’s a list of some specific things that I really like about Ruby. Some of them are obvious, and some are shared with other languages. The purpose is to share things I like about Ruby, not to compare and contrast with any specific language."
======
defunkt
Unfortunately _try_ illustrates the exact problem with open classes so many
non-Rubyists are afraid of: collisions.

 _try_ was originally defined as:

    
    
      class Object
        def try(method)
          send method if respond_to? method
        end
      end
      

In Rails it is defined as:

    
    
      class Object
        alias_method :try, :__send__
      end
    
      class NilClass 
        def try(*args)
          nil
        end
      end
    

The following code will exhibit different behavior depending on which version
of _try_ you're using:

    
    
      [].try :upcase
    

For example:

    
    
      # original try
      >> [].try :upcase
      => nil  
    
      # rails try
      >> [].try :upcase
      NoMethodError: undefined method `upcase' for []:Array
    

If Rails uses _try_ internally, and a Rails plugin you've loaded depends on
the original version of _try_ , what now? They both behave differently and,
presumably, code using them depends on their specific behavior.

Also don't forget the dozen or so other versions of _try_ people have added to
their own plugins and apps...

~~~
dylanz
Articulated perfectly! Any time I'm working on a Rails project, and run into
odd behaviours, the first thing I'll do is check to see if I'm actually using
a Ruby or a Rails method. Most often than not, I'm expecting a "Ruby" way of
doing things, but find out I'm actually using the "Rails" version, which does
something completely different. If I run into any in the next few hours, I'll
post them here :)

~~~
carbon8
It's not really a Ruby vs Rails way of doing things. The Rails implementation
is arguably more in line with the standard Ruby behavior since it throws a
NoMethodError for everything other than Nil objects.

~~~
defunkt
I would argue that, no, there isn't "standard Ruby behavior" in this instance.
It's just a method.

~~~
carbon8
True, they are all just methods, but it's basically just an altered version of
Object#send, and the current Rails implementation only significantly differs
from it in the specific situation it's intended for.

I realize there are a range of preferences regarding ways to tackle the
problem this is intended to solve, and I'm relatively agnostic about the
overall issue, but if the implementation is basically a #send that guards
against nil, then it would be unexpected for it to deviate remarkably from
#send when dealing with non-nil objects.

------
mpk
I love reading articles like this. 8 years or so ago Ruby replaced Perl for me
as my 'go to' language for day-to-day problems. I haven't looked back since.

What other people call 'magic', I call not understanding the language and
execution environment.

For long-running server-side stuff Ruby would not be my first choice, but for
eloquence and scripting capabilities... accept no substitute.

------
tptacek
Not everything in Ruby is a full-fledged class; for instance, you can't extend
Fixnum.

[I am apparently completely wrong here].

~~~
nudded

      class Fixnum
        def +(other)
          42
        end
      end
    

3 + 2 => 42

~~~
railsjedi
I try to sneak this into all of my rubygems

