C:>irb --simple-prompt
DL is deprecated, please use Fiddle
class Foo
def talk
p “huanng”
end
end
=> nil
module Bar
def talk
p “hunnggg”
end
end
=> nil
foo = Foo.new
=> #Foo:0x20493c0
class << foo
def talk
super
return
p “hukkangg”
end
include Bar
end
=> #<Class:#Foo:0x20493c0>
part - A
foo.talk
“hunnggg”
=> nil
Part - B
foo.class.instance_method(:talk).bind(foo).call
“huanng”
=> “huanng”
Can anyone help me to understand the difference between the two call to
talk? or How part B bypass the call to singleton method talk to
class Foo s talk ?
foo.class.instance_method(:talk) is specifically the method that
returns “huanng” (you need to pick less ambiguous choices of output)
class Foo
def talk
p “talk”
end
end
Foo.instance_method(:talk)
=> #<UnboundMethod: Foo#talk>
If you bind it to an object, it is no longer unbound:
Foo.instance_method(:talk).bind(Foo.new)
=> #<Method: Foo#talk>
You’re calling this Method instance, using the state in your instance
of Foo. This is different from sending message to an instance of Foo
(with foo.talk) and letting it do a method look-up. In the latter
case, it sees the singleton method as part of the look-up.
What I know singleton methods can be called by the objects, on which it
is defined. Now in the below example C is also
an object of Class and singleton method a_class_method defined on
the Class object C. So how does another Class object D able
to call a_class_method? How does object individuation principle
holds in this example?
class C
end
#=> nil
def C.a_class_method
puts “Singleton method defined on #{self}”
end
#=> nil
C.a_class_method
#Singleton method defined on C
#=> nil
class D < C
end
#=> nil
D.a_class_method
#Singleton method defined on D
#=> nil
Love U Ruby wrote in post #1101669:
What I know singleton methods can be called by the objects, on which it
is defined. Now in the below example C is also
an object of Class and singleton method a_class_method defined on
the Class object C. So how does another Class object D able
to call a_class_method? How does object individuation principle
holds in this example?
class C
end
#=> nil
def C.a_class_method
puts “Singleton method defined on #{self}”
end
#=> nil
C.a_class_method
#Singleton method defined on C
#=> nil
class D < C
end
#=> nil
D.a_class_method
#Singleton method defined on D
#=> nil
If you did D.method :a_class_method you’ll see:
#<Method: D©.a_class_method>
This happens because D’s singleton class inherits from C’s singleton
class, which happens because D inherits from C (and as such, D is C).
Why the singleton methods can’t be defined on
Fixnum,Bignum,Float,Symbol class objects, but FalseClass and
TrueClass can have?
C:\>ruby -v
ruby 2.0.0p0 (2013-02-24) [i386-mingw32]
C:\>irb --simple-prompt
DL is deprecated, please use Fiddle
11111111111.class
#=> Bignum
# class << 11111111111 ; end
#TypeError: can't define singleton
# from (irb):2
# from C:/Ruby200/bin/irb:12:in `<main>'
1111.class
#=> Fixnum
class << 1111 ; end
#TypeError: can't define singleton
# from (irb):4
# from C:/Ruby200/bin/irb:12:in `<main>'
11.11.class
#=> Float
class << 11.11 ; end
#TypeError: can't define singleton
# from (irb):6
# from C:/Ruby200/bin/irb:12:in `<main>'
:name.class
#=> Symbol
class << :name ; end
#TypeError: can't define singleton
# from (irb):8
# from C:/Ruby200/bin/irb:12:in `<main>'
true and false object also has fixed object_id. Why are then they
allowed to have singleton methods on them?
C:\>irb --simple-prompt
DL is deprecated, please use Fiddle
def true.test ; end
#=> nil
class << true
def show
p "How possible?"
end
end
#=> nil
true.show
#"How possible?"
#=> "How possible?"
true.object_id
#=> 2
true.object_id
#=> 2
class << false
def show
p "How possible?"
end
end
#=> nil
false.show
#"How possible?"
#=> "How possible?"
false.object_id
#=> 0
false.object_id
#=> 0
Think about it. You’re trying to define directly on a NUMBER, even
though its class is BigNum, numbers can’t have singletons assigned to
them. Now if you did class << BigNum that’d be different.
Same thing for when you attempt to assign to a symbol. Now if you did
class << Symbol that’d be different.
Dude, if you’re going to try complex stuff like this, use your friggin
head. You keep attempting to do dumb ass stuff, but don’t have a clue to
what you’re doing. You’re not thinking, nor even attempting to reason it
out. It didn’t dawn on you that NUMBERS are different than their base
class? What good would defining a singleton on the number 11 do?
NOTHING!
p “huanng”
=> #Foo:0x20493c0
part - A
Can anyone help me to understand the difference between the two call to
talk? or How part B bypass the call to singleton method talk to
class Foo s talk ?
–
D. Deryl D.
“The bug which you would fright me with I seek” - William Shakespeare
- The Winter’s Tale, Act III, Scene II - A court of Justice.
That nasty thing google again - it always amazes me why they put
descriptions of errors sometimes.
“can’t define singleton ruby”
You’re welcome as usual
John
D. Deryl D. wrote in post #1102022:
Dude, if you’re going to try complex stuff like this, use your friggin
head. You keep attempting to do dumb ass stuff, but don’t have a clue to
what you’re doing. You’re not thinking, nor even attempting to reason it
out. It didn’t dawn on you that NUMBERS are different than their base
class? What good would defining a singleton on the number 11 do?
NOTHING!
I don’t know how much you understand my above question,which is so
valid.
From the doc: Class: Fixnum (Ruby 2.0.0)
Clearly mentioned that - *There is effectively only one Fixnum object
instance for any given integer value, so, for example, you cannot add a
singleton method to a Fixnum.
The same I agreed for Bignum,FLoat and Symbol.
Now the true,false and nil also has fixed Object_id, But why they
are allowed to have singleton class on them. – This is my curiosity to
know and I think which is to legitimate.
Thanks.
Hans M. wrote in post #1102040:
true.singleton_class #=> TrueClass
false.singleton_class #=> FalseClass
nil.singleton_class #=> NilClass
thats why each try to define singleton classes on this objects are
turned into normal method defining on the real classes
Thanks Hans. It sounds good. I tried the same in my IRB. But didn’t
think that way.
The most valuable thing that I learned from here is the “Thinking
Approach”, which is helping a lot.
@John thank you also. As I got some more valuables thing to read from
the search “can’t define singleton ruby”. 
Thanks as usual.
true.singleton_class #=> TrueClass
false.singleton_class #=> FalseClass
nil.singleton_class #=> NilClass
thats why each try to define singleton classes on this objects are
turned into normal method defining on the real classes