Forum: Ruby Confusion in instance method calls of super class from subclass

I was just playing to see the instance method calls from the subclass
and used the below code of my test:

    class Animal
      def bark
        p "hukkhh"
      end
    end
    #=> nil

    class Cow < Animal
    end
    #=> nil

    Cow.public_instance_method(:bark)
    #=> #<UnboundMethod: Cow(Animal)#bark>

    class Cow
      bark
    end
    #=> NameError: undefined local variable or method `bark' for
Cow:Class
    #        from (irb):11:in `<class:Cow>'
    #        from (irb):10
    #        from C:/Ruby193/bin/irb:12:in `<main>'

From that code I was confirmed that instance method can't be executed
without the object instance of the respective class.

But then I tried below code:

    def talk
      p "hi"
    end
    #=> nil

    Object.public_instance_method(:talk)
    #=> #<UnboundMethod: Object#talk>

    class Foo
      talk
    end
    # prints: hi
    #=> "hi"

Here the output made me confused with my first test code output.

Could anyone help me to understand the fact behind these above?

Why do you think? You added #talk to Object, Foo inherits from Object, 
so
it works.

classes are instances of Class, and this is a child class of Object

so methods defined in Object class works in other classes too

D. Deryl Downey wrote in post #1099862:
> Why do you think? You added #talk to Object, Foo inherits from Object,
> so
> it works.


Yes, you are absolutely right. But my confusion was with `Cow` class 
which is a subclass of `Animal`. and the `Animal` class has the `public 
instance method` `bark`. Now as `talk` method defined in the top 
level,why the bare called to `bar` has been denied from the `Cow` class. 
I might have some wrong conception here I am sure.

Could you clarify on that regard?

Thanks for showing your interest.

the main object is different ... everything that is defined there is 
automatic defined as private method in the Object class too

Hans Mackowiak wrote in post #1099873:
> the main object is different ... everything that is defined there is
> automatic defined as private method in the Object class too


@Hans if you see my code above,you will find that`talk` is being added 
as `public` method but not as `private` method.

One more thing is that as below:


C:\>irb --simple-prompt
>> def talk
>>       p "hi"
>> end
=> nil
>> Object.public_instance_method(:talk)
=> #<UnboundMethod: Object#talk>
>> Object.public_method(:talk)
=> #<Method: Class(Object)#talk>
>>

Why `talk` has been added as `class method and instance method` as well. 
Could you help me to understand the logic?

Thanks in advance. :)

YOU DID NOT READ WHAT I WAS WRITTEN:

>> classes are instances of Class, and this is a child class of Object
>> so methods defined in Object class works in other classes too

its not added as a class method, but because each class is an Object,
methods are defined in the Object class are callable from EACH OTHER 
OBJECT TOO, INCLUDING EACH OTHER CLASS OBJECT!

Hans Mackowiak wrote in post #1099900:
> YOU DID NOT READ WHAT I WAS WRITTEN:
>
>>> classes are instances of Class, and this is a child class of Object
>>> so methods defined in Object class works in other classes too
>
> its not added as a class method, but because each class is an Object,
> methods are defined in the Object class are callable from EACH OTHER
> OBJECT TOO, INCLUDING EACH OTHER CLASS OBJECT!

Okay! That I saw. I mentioned that its as public method not the private 
one. as you said - "the main object is different ... everything that is 
defined there is automatic defined as **private** method in the Object 
class too".

I understood why `talk` succeeded. MY confusion was with the `bar` call 
DUDE. :)

On Mar 3, 2013, at 01:39 , "Kumar R." <lists@ruby-forum.com> wrote:

> I understood why `talk` succeeded. MY confusion was with the `bar` call
> DUDE. :)

That confusion is because you're a moron who refuses to follow any of 
our advice... like READING a book or even a website in order to learn 
the language and basic concepts around object oriented programming. As 
MANY have pointed out already, you have yet to learn the difference 
between instances and classes as well as instance methods and class 
methods. Once you understand that VERY SIMPLE CONCEPT that many here 
have pointed you at, all of these questions fall away and you have the 
opportunity to possibly be an asset to this community instead of a help 
vampire.

Ryan Davis wrote in post #1099902:
> On Mar 3, 2013, at 01:39 , "Kumar R." <lists@ruby-forum.com> wrote:
>
>> I understood why `talk` succeeded. MY confusion was with the `bar` call
>> DUDE. :)
>
 all of these questions fall away and you have the
> opportunity to possibly be an asset to this community instead of a help
> vampire.

So you are insisting someone not to ask questions, and only to answers.
But if no one ask any questions then what's the purposes of community.
It's really I think to help someone who stuck. And the links and books 
you are referring they itself told if any confusion ask in the 
community. But
community members Like Ryan you disobeyed that. First you think and tell
me to whom should I hear ?


This is a very legitimate question from the beginner.


Thanks

my guess Cow is meant to be made a class of Object first before calling 
it
if left unclear it is either a method or object hence your bark is lost

Am 03.03.2013 11:06, schrieb Kumar R.:
> I think to help someone who stuck. And the links and books you are
> referring they itself told if any confusion ask in the community. But

But you have to *try harder* reading them *first*.

You are really the most annoying poster I ever encountered in the
2 something years I'm in this list. You repeatedly insult us
and make people shout at each other and turn away form this list,
where right now YOU take up about 50% of the traffic!

Have you ever tried to write a program with more than 5 lines?
One that actually *does* something?

You try to learn the language on a theoretical level that has really
no relevance to the things you should care about as a beginner.
For example, up to now I had *never* to care about the return value
of a class or method definition. For what do you need them...?
In case you don't need them right now for a very specific purpose,
that's just wasted time you should spend better.

unknown wrote in post #1099908:
> Am 03.03.2013 11:06, schrieb Kumar R.:
>> I think to help someone who stuck. And the links and books you are
>> referring they itself told if any confusion ask in the community. But
>
> But you have to *try harder* reading them *first*.
>

> You try to learn the language on a theoretical level that has really
> no relevance to the things you should care about as a beginner.
> For example, up to now I had *never* to care about the return value
> of a class or method definition. For what do you need them...?
> In case you don't need them right now for a very specific purpose,
> that's just wasted time you should spend better.

Yes, theory is first essentials rather than problem solving.

If you don't know what's the value of Sin30 then how would you solve the 
equation sin 30 + cos 30 ?

Programming language works also that way. First concept and then problem 
solving skills. And problem solving is not a great challenge to any one 
who did it already with other languages.

To know the features of a specific language is the very essentials one.

This is very humble request to you not to make my thread dirty,so that 
future reader would end up their internal patience before reaching to 
ultimate information.

Don't say I underestimate others, which in turn others did with me. I 
here just asked question that raised in my mind.

Am 03.03.2013 12:34, schrieb Kumar R.:
> Yes, theory is first essentials rather than problem solving.
>
> If you don't know what's the value of Sin30 then how would you solve the
> equation sin 30 + cos 30 ?

EXACTLY.
And you didn't learn what 1+1 is but are trying to understand sin.

BTW:
1. you probably meant sin(30°), and
2. sin(30°) + cos(30°) is not an equation.

> To know the features of a specific language is the very essentials one.

Agreed, but you have to start with the *basic* features,
not with implementation details that have no relevance whatsoever
for 99% of the code that people write.

> This is very humble request to you not to make my thread dirty,so that
> future reader would end up their internal patience before reaching to
> ultimate information.

You make this whole list "dirty", and many list members already have
lost their patience.

To avoid further dirt, please do not answer this post.

unknown wrote in post #1099911:
> Am 03.03.2013 12:34, schrieb Kumar R.:
>> Yes, theory is first essentials rather than problem solving.
>>
>> If you don't know what's the value of Sin30 then how would you solve the
>> equation sin 30 + cos 30 ?
>

> BTW:
> 1. you probably meant sin(30°), and
> 2. sin(30°) + cos(30°) is not an equation.

I thought you are well capable of why I used the above example. Because
`hints` is enough for smart people.


> To avoid further dirt, please do not answer this post.

Yes, I should,as you again insult me.

EXACTLY.
And you didn't learn what 1+1 is but are trying to understand sin.

You might have the perception that CAT= TIGER. Then there is no rule
that others should believe.

Am 03.03.2013 13:25, schrieb Kumar R.:
> I thought you are well capable of why I used the above example. Because
> `hints` is enough for smart people.

This is only another example on how "well" you do your reading/research.
You also for example don't even care to remove typos from your posted
code examples that you had noticed yourself. That's "dirtying" a thread.

> Yes, I should,as you again insulted me.

No, it's you that keeps insulting people who are trying to
give you advice on what is not worth learning at this stage.

 From now on I will ignore your posts completely, even if
they should happen to contain some valid question.