Difference between Proc and Lambda

Proc and Lambda are used to create code blocks. After creating them, we can pass them around our code, just like variables.

But there are 2 significant differences we have to keep in mind.

1. Suppose a Proc or a lambda is used to create a code block inside of a method. If the Proc/Lambda has a return statement inside of its code, in the case of Proc, the whole method is returned. But in the case of Lambda, its not. The execution continues to any further statements inside the method. Here is the code fragment that explains this difference.

2. A Proc will not check if the arguments are passed to it are of the same number as its parameters. A Lambda will throw an error if we violate the number of parmeters.




You see, Proc is very naughty :) It won't check for the number of arguments and it will return without the permission of the method in which it resides!

RVM, RubyGems and Bundler - How gems are installed ?

Earlier when I started programming using ruby (system ruby), it was all clean. I used to install gems with sudo gem install somegem . Then came rvm and it asked me to install gems without sudo like: gem install somegem. Then came bundler, which asked me to install gems by bundle install.

Since then, I was confused about how things work using these 2 tools on top of ruby. Well, I decided to put an end to that confusion and here is how they work.

When you use



rubygems would install that gem in the place defined by $GEM_HOME environment variable. Now this is the variable that dominates where rvm puts gems in and where bundler puts gems in.

I suppose you are using rvm to manage multiple rubies. When you switch rubies using rvm, the $GEM_HOME variable changes. rvm changes it.



When we use bundler install to manage dependencies, bundler simply call gem install under hood for each of the gems defined in Gemfile. Lets see this in terminal.

First create a new rails project, it comes with a Gemfile.



Lets then create a new gemset for this project and use it



Install bundler and check $GEM_HOME location for any gems installed.



Do a bundle install in this project and check $GEM_HOME again.

'class << ' merely changes the self

Many ruby programmers use class << self inside some class definition to create class methods. But the actual meaning behind this class << self is completely different. Using it for creating class methods is just one usecase.

class << soomeobject, actually changes 'self' object inside a definition block. In ruby, in any place there is something called as current object or 'self'. If you are calling a method and if you don't specify a receiver or object on which the method has to be called (like someobject.methodname() ), the method will be called on 'self' or current object inside that scope.

Object Dynamism in Ruby

When an object in Ruby is created, it has methods and instance variables that are initially defined in its class. But that doesn't stop that object from getting new capabilities. They get more powers later by their singleton classes or when their parent class gets new methods. Let me tell you about the first way.

Every object have its own class (apart from the class from which it was instantiated). That class is called as singleton class (or some would call it ghost class, eigen class, uniclass, etc.,). Singleton classes are unique to an object. And ruby will look for methods in that class before it looks into a class, when a method is called on that object. Here is code snippet that demonstrates singleton class.

super is a keyword, not a method call!

Methods can be overridden in subclasses of ruby. It is just a process of rewriting method definition, as it make sense in the current class/object.

Calling super .. oops, sorry - writing super anywhere in the over-ridden method will cause the method lookup to continue and the execute the first method found by the name. (If you want to learn about method lookup, here is a good writeup by Gregory Brown. Here are some examples of how super can be used.