0

I want to know how ruby interpreter works.Well let's look at the bellow In irb console if write

Class.is_a? Class #=> returns -> true

I would like to know how this is returning true. What is happening underneath.

class A
  def hello
    puts 'hello'
  end
end
A.is_a? A # returns false

Why it's returning false here? Can someone explain how this is being done underneath.I am not asking for Ruby obeject class hierarchy but look Class.is_a? Class is true then A.is_a? A should be true because A is a Class.But A.is_a? A is false why?
Another example 

Module.is_a? Class # returns true
Class.is_a? Module # returns true

I mean how? Because Module can't be instantiated where Class can be and there are other differences as well between Mudule and Class. Then how come those expression returning true that means there are some logic behind this. Can someone explain that logic or the magic happening here. I am really interested to know this. Please help me understand Ruby interpreter technique
Thanks in advance.

monsur
  • 601
  • 6
  • 18
  • 1
    `Class.class #=> Class`. All classes are instances of `Class`. Since `Class` is a class, it is itself an instance of `Class`:). Confused? You should be! & btw this seems like a dup but I can't find a link atm. – Sagar Pandya Apr 14 '17 at 18:18
  • Seriously confused.Because `Module.ancestors` => `[Module, Object, Kernel, BasicObject]` and `Class.ancestors` => `[Class, Module, Object, Kernel, BasicObject]`.So Module is a ancestors of `Class`.But how they are tied togather.This is not the reason they have common ancestors.But there are other reasons here.BTW I have searched for same type of question but didn't get any. – monsur Apr 14 '17 at 18:26
  • `Module.is_a? Class #=> true` this makes sense because Module is a class; `Class.is_a? Module #=> true` since `Module` is a superclass of `Class` i.e. `Class` is an instance of `Class` which means it's a specialised `Module` so to speak. Anyway the link for which this question is a dupe covers everything. Best of luck down the rabbit hole. I admire you for seeking out how this all works... it's pretty fascinating. – Sagar Pandya Apr 14 '17 at 18:44
  • I went through that url but that does satisfy me.So here is the biggest confusion `class A def hello puts 'hello' end end class B < A def hello puts 'hello' end end class C < A def hello puts 'hello' end end ` According to your @sagarpandya82 comment `B.is_a? C` should return `true` as they are inheriting from class `A` but it is returning `false`.Do you know why?So I think this question is really not like that you said.Please remove the duplicate mark. – monsur Apr 14 '17 at 18:52
  • 1
    @monsur that comment is very unclear. First due to inheritance neither `B` nor `C` would require you to redefine `hello` in an identical fashion. Second `B` and `C` are not an `A`. `A`, `B`, and `C` are classes meaning `is_a?(Class) #=> true` because they are instances of the class Class. but `B.new` and `C.new` are `A`'s because the are instances of their class which is a subclass of `A`. That being said `A`,`B` and `C` are all `Module`s as well by the virtue explained above but their instances are not meaning `B.new.is_a?(Module) #=> false` – engineersmnky Apr 14 '17 at 18:57
  • @sagarpandya82 here the `hello` method is not the fact.`A.class` => `Class` and `B.class` => 'Class' then why not `A.is_a? B` as both A and B are the instance of `Class` – monsur Apr 14 '17 at 19:05
  • @monsur one of the easiest ways to understand this is that `is_a?` concerns itself with `class`, inheritance and inclusions (which create a sudo anonymous superclass). e.g. `A.class #=> Class` thus `A` is a `Class`. `B.new.class #=> B` and since B inherits from `A` an instance of `B` is an `A`. further more `module R;end; class D; include R; end` now D is not an `R` because `D` is a `Class` as previously established but `D.new` is a `R` because `R` has been injected into the inheritance chain for instances of `D` e.g. `D.ancestors #=> [D,R(Module),Object,Kernel(Module),BasicObject]` – engineersmnky Apr 14 '17 at 19:06
  • It's pretty difficult to offer detailed explanations in comments, so I will cease to do so now. I can however offer you two more links: [link1](http://stackoverflow.com/q/34498578/5101493) and [link2](http://stackoverflow.com/q/7675774/5101493) which both provide excellent answers and discussion in keeping with how the core classes are structured. Take your time to understand this, they are tricky. – Sagar Pandya Apr 14 '17 at 19:12
  • @mosur to answer your last comment why is a Flower not a Tree they are both Plants? Why is a Monkey not a Fish they are both Animals? But a Tulip (an instance of a Flower) is a Flower and a Plant and a Blowfish (an instance of a Fish) is a Fish and an Animal. – engineersmnky Apr 14 '17 at 19:12
  • @engineersmnky yes exactly.A monkey is not a fish even though they are animals then how come a `Module` is a `Class` what's happening here then.Certainly there is some logic. – monsur Apr 14 '17 at 19:18
  • 2
    @monsur: "a `Module` is a `Class`" – No, it's not. `Module` is a `Class`, **a** `Module` is a `Module`. – Jörg W Mittag Apr 14 '17 at 19:39
  • @monsur as @JörgWMittag pointed out **a** `Module` is not a `Class` the `Class` `Module` is a `Class`. So let's try it out `module R;end` then `R.is_a?(Class) #=> false` – engineersmnky Apr 14 '17 at 19:47
  • Take a look at the book Ruby Under a Microscope An Illustrated Guide to Ruby Internals By Pat Shaughnessy (http://shop.oreilly.com/product/9781593275273.do). you can also read his blog http://patshaughnessy.net/ – suhao399 Apr 15 '17 at 02:23

0 Answers0