Click here to Skip to main content
13,511,701 members
Click here to Skip to main content
Add your own
alternative version

Tagged as


Posted 19 Oct 2011

Crazy Ctor Concept in Ruby [TIP]

, 19 Oct 2011
Rate this:
Please Sign up or sign in to vote.
Crazy Ctor concept in Ruby

In Ruby as we know, the ctor like concept is actually called initializers. Hence, there is not really a constructor in Ruby (perhaps I have not found it even after Googling for hours so far).

So to initialize all your local class data in Ruby, you have to do something like this:

class Myclass

def initialize(firstArgument, secondArgument)
@firstArg = firstArgument
@secondArg = secondArgument

def SomeMethod
puts @firstArg + @secondArg

instance ="hello"," world")

As per the above code, initialize() method is the initializer for this class. So the ruby interpreter automatically calls this method (initializer) when you use new keyword over the class name as per above code. A point worth mentioning here is that, Ruby does not support method overloading like other languages, same is true for ctor.

But be aware here that the initializer does not always call new to create an object here, it may sometimes call allocate to create classes. What it actually means is, if an object is already in the database (created earlier or something) then the same object is just allocated memory and all its internal data will be null on other hand by saying new, it creates a fresh memory for the object (brand new instance) with all its internal data being set or defined.

Now as per the above code, I have not specified any access modifiers, viz, private, public, etc. for the method initialized in the above code. So as per the Ruby doc, by default, all methods are public for a class but not for this initialize method though. Even if you explicitly provide a modifier to this method as public, still Ruby treats it as private method.

So we can see that the Ruby interpreter does actually find initialize method on a type on which new is used even though this method is private. So it is suggested by Ruby experts/geeks not to rely on initializer method in case you are overriding this method to do some custom initialization mechanism.

At first, I got a bit curious that even specifying a modifier to this method still I was not able to call it explicitly using an instance. To find out if what's said everywhere is really true (you can call me crazy), I used Object.respond_to?() method to check if the method exists in this type, i.e., MyClass in the above code. So I did some modifications to the above code:

if instance.respond_to?("initialize")

The if condition never gets passed, because respond_to? method cannot find specified method in the MyClass instance. So I provided include_private=true as a second argument for this respond_to?() method. Then it was able to find the specified method, and thus the condition passed, but hey the call inside the if body does throw an exception/error saying that private method is called.

Another way to prove this method is private is by using Module.private_methods() API on MyClass type. It shall list all the private methods MyClass has and up the root hierarchy. So as per its output, this initialize method gets listed. So that also proves that Ruby no matter what I do, still treats initialize method as private only.

Thanks for reading!

P.S.: Your comments/votes are much appreciated.


This article, along with any associated source code and files, is licensed under The GNU Lesser General Public License (LGPLv3)


About the Author

Software Developer (Senior) Siemens
India India
A .net developer since 4+ years, wild, curious and adventurous nerd.

Loves Trekking/Hiking, animals and nature.

A FOSS/Linux maniac by default Wink | ;)

An MVP aspirant and loves blogging ->

You may also be interested in...


Comments and Discussions

-- There are no messages in this forum --
Permalink | Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.180417.1 | Last Updated 19 Oct 2011
Article Copyright 2011 by zenwalker1985
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid