E X P R E S S I C A

NOTE : This post may contains repeated and boring stuff for those who already have the programming practice of DuckTyping.

What is Duck Typing ?
Duck Typing is Dynamic Typing
In ruby we do not declare the type of the variable. It automatically becomes the object of the related class. For example, if we assign str = “hello string” then the variable str will automatically becomes the object of class String, that we can confirm by issuing str.class. But according to Duck Typing philosophy even Classes are not Types.
That is the basic rule of Duck Typing is that THE TYPE OF OBJECT IS DETERMINED BY WHAT IT CAN DO, NOT BY ITS CLASS. Lets exemplify the statement…
[source:ruby]
obj = nil

[/source]
now here the object obj is a NilClass object but (in ruby) it will be wrong to say that obj is a NilClass type object. The statement is confining the tasks that can be performed by it. Coz we can have the object obj as a NilClass object and still performing singleton functionalities declared over it. Like …
[source:ruby]
obj = (def wish; puts “good morning, lets code like a Duck :)”; end)
obj # => nil
obj.class # => NilClass
obj.wish # => good morning, lets code like a Duck [/source]

So, even a nil object can wish you good morning! Here a method wish has been added to a nil object. But it will not be available for all nil objects, or will that be ? Well, thats a homewok for you!!
Check this out, in this case the wish method will be available for all the nil objects… and the reason is that all the nil objects actually points to a same preserved nil object in the ObjectSpace but not creates a new object everytime like in most cases. Well, i will discuss more deeply regarding the ObjectSpace very soon.

Moreover, extending the modules over an object both at run time and compile time is itself a functionality supporting the statement that Classes are not types and this is what Duck Typing is.

Why known as Duck Typing ?

Alex Martelli, a member of the Python Software Foundation , have given the name DuckTyping to this approach in reference with Duck Test … which says that When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.
So, if an object is behaving like string the it is string type object but not if only it have the class as String.

Update: SimpleCaptcha 1.2.2 is up!!

Major Changes…

FileSystem Usage Removed

Works Perfectly with Multiple Clustered Servers

Read Here for more details on implementation, usage and examples.

Doing meta-programming in ruby gives all new ways of getting closer to ruby. There are a lots of Ruby Idioms that attracted a lots of programmers to fall in love with Ruby-Lang. class << self; self; end is a ruby idiom which gives the Big Picture of coding-less and producing-more by providing the way to add an anonymous class to any class which is an instance of class Class. And singleton class can be implemented to any class which will be equally good as implementing it on any object and the reason is that every class that we define with class is again an instance of a class Class. And the beauty is…
[source:ruby]
“string”.class # => String
“string”.class.class # => Class
“string”.class.class.class # => Class
“string”.class.class.superclass # => Module
“string”.class.class.superclass.class # => Class
“string”.class.class.superclass.superclass # => Object
“string”.class.class.superclass.superclass.class # => Class
“string”.class.class.superclass.superclass.superclass # => nil
[/source]

class << self; self; end
Lets try what exactly this idiom returns
[source:ruby]
class A
puts self
puts(class << self; self; end)
end
# => A
# => # <Class:A>
[/source]

As it is cleared from the output that inside the class A, self is reflecting the class A itself whereas class << self; self; end is <Class:A>, so what is the exact difference ?
Lets exemplify it…
[source:ruby]
class A

self.module_eval do
define_method :wish do
puts “hello instance method”
end
end

(class << self; self; end).module_eval do
define_method :wish do
puts “hello class method”
end
end

end

A.wish # => hello class method
A.new.wish # => hello instance method

class B

self.module_eval do
define_method :wish do
puts “hello instance method”
end
end

end

B.new.wish # => hello instance method
B.wish # => undefined method `wish’ for B:Class (NoMethodError)

[/source]

I suppose that it is clear now, in case if it is not than look at this… The following code will do exactly same as above but the class method wish will be available to all classes or we can say to all instances of class Class

[source:ruby]

class Class

self.module_eval do
define_method :wish do
puts “hello — this is class method for instance of class Class”
end
end

end

class A

self.module_eval do
define_method :wish do
puts “hello instance method”
end
end

end

A.wish # => hello — this is class method for instance of class Class
A.new.wish # => hello instance method

class B

self.module_eval do
define_method :wish do
puts “hello instance method”
end
end

end

B.wish # => hello — this is class method for instance of class Class
B.new.wish # => hello instance method

[/source]

Yokihiro Matsumoto (Matz)

The Living Legend, The Great Person, The Matz.
Creator of Ruby, the most beautiful programming language.