How to know in which class we are when inheriting

Look at this code:
class One
def initialize
puts self.class
end
end

class Two < One
def initialize
super()
puts self.class
end
end

Two.new()

I want to know that when in initialize in One Class we are in One class
and when in Two the same… but it seems that Ruby thinks that we are
always in Two… any idea how to do this?
btw I’m using Ruby 1.8.7

Hi,

the “self” keyword is always resolved in the current context. So when
you call an inherited method or super(), “self” always points to the
current instance and not the originating class or something. This
wouldn’t even make sense in your case, because there is no instance of
One that “self” could refer to.

If you want to know the class where a certain method is defined, use
Method#owner:

#-----------------
class A
def f
puts method(:f).owner
end
end

class B < A; end

b = B.new
b.f
#-----------------

However, I have a bad feeling about what you’re going to do with this.
What are you trying to do?

Well, it is more complicated what i want to do… but doint it like you
said i got the first class where all the others are inheriting from…
and that’s not what i want.

Take a look at this example more similar to the thing I need:
(I need to know that what is failing is the setup on class Two)

require ‘test/unit’

#This is the TestCase class inside the framework i’m developing
class TestCase < Test::Unit::TestCase
undef_method :default_test
def whoami
return method(:whoami).owner
end

  def assert(value,*message)
    report(value,message.join)
    return super(value,message.join)
  end

  def report(value,*message)
    if value==false then
      puts "*" * 20
      puts whoami
      puts "#" * 20
    end
  end

end

#I want people to write testcases using my new testcase class, like
these ones
class One < TestCase
def setup
super()
assert(true,“blabla”)
end

end

class Two < One
def setup
super()
assert(false,“dos”)
end
end

class MyTestCase < Two
def test01
assert(true,“hola”)
end
end

Jan E. wrote in post #1086850:

Hi,

the “self” keyword is always resolved in the current context. So when
you call an inherited method or super(), “self” always points to the
current instance and not the originating class or something. This

Hey Robert it doesn’t work for me that way, i’m using 1.8.7 and i cannot
use 1.9

Robert K. wrote in post #1086879:

On Wed, Nov 28, 2012 at 12:51 PM, Mario R. [email protected]
wrote:

Well, it is more complicated what i want to do… but doint it like you
said i got the first class where all the others are inheriting from…
and that’s not what i want.

Well, but that’s the way it is. :slight_smile:

Take a look at this example more similar to the thing I need:
(I need to know that what is failing is the setup on class Two)

You can see that from the stack trace. And you can also provide
meaningful comment.

$ ruby x.rb
/usr/lib/ruby/gems/1.9.1/gems/minitest-4.3.0/lib/minitest/unit.rb:192:in
assert': in two (MiniTest::Assertion) from /usr/lib/ruby/1.9.1/test/unit/assertions.rb:38:inassert’
from x.rb:15:in initialize' from x.rb:19:innew’
from x.rb:19:in `’

$ cat -n x.rb
1
2 require ‘test/unit’
3
4 class TC < Test::Unit::TestCase
5 end
6
7 class One < TC
8 def initialize
9 assert true, “in one”
10 end
11 end
12
13 class Two < One
14 def initialize
15 assert false, “in two”
16 end
17 end
18
19 t = Two.new
20

Cheers

robert

C:/Ruby187/lib/ruby/1.8/test/unit/testcase.rb:125:in add_assertion': undefined methodadd_assertion’ for nil:NilClass (NoMethodError)
from C:/Ruby187/lib/ruby/1.8/test/unit/assertions.rb:494:in
_wrap_assertion' from C:/Ruby187/lib/ruby/1.8/test/unit/assertions.rb:61:inassert’
from xxx.rb:14:in initialize' from xxx.rb:18:innew’
from xxx.rb:18

Robert K. wrote in post #1086914:

On Wed, Nov 28, 2012 at 2:48 PM, Mario R. [email protected]
wrote:

Hey Robert it doesn’t work for me that way, i’m using 1.8.7 and i cannot
use 1.9

I am surprised that 1.8 behaves differently. What happens if you
execute the code I posted with 1.8.7?

Cheers

robert

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs