Class Methods and derivation

ruby-talk
1

I do something like the following

class Test
  def Test.open
    tt=Test.new
    yield tt
    tt.close
  end
end

class DerivedTest<Test
  include SomeModule
end

Obviously the following will fail

DerivedTest.open{|tt|
  tt.some_module_method
}

so I moved open to DerivedTest.

Can I write a class method that instantiates the proper derived class?
I need a way to find the class of the caller and instantiate that :slight_smile:
Am I asking for the impossible? I think not, since IO.open does this, although the code is C - the call to rb_class_new_instance obviously instantiates the proper class. How can I do that in pure Ruby?
Cheers,
V.-

···

--
http://www.braveworld.net/riva

____________________________________________________________________
http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ.
http://www.freemail.gr - free email service for the Greek-speaking.

2

I do something like the following

Try something like this

moulon% cat b.rb
#!/usr/bin/ruby
class Test
   def self.open
      tt = new
      yield tt
   ensure
      tt.close if tt
   end

   def close
   end
end

module SomeModule
   def some_module_method
      puts "some_module_method"
   end
end

class DerivedTest<Test
   include SomeModule
end

DerivedTest.open{|tt|
   tt.some_module_method
}
moulon%

moulon% ./b.rb
some_module_method
moulon%

Guy Decoux

3

ts wrote:

I do something like the following

Try something like this

moulon% cat b.rb
#!/usr/bin/ruby
class Test
   def self.open
      tt = new
      yield tt
   ensure
      tt.close if tt
   end

   def close
   end
end

module SomeModule
   def some_module_method
      puts "some_module_method"
   end
end

class DerivedTest<Test
   include SomeModule
end

DerivedTest.open{|tt|
   tt.some_module_method
}
moulon%

moulon% ./b.rb
some_module_method
moulon%

Guy Decoux

Guy, you were too fast again! :slight_smile: So I cut out my similar example and
just add what would have been my explanation:

The trick is not to do Test.new but to use just new (calls self.new which
is DerivedTest in sub class).

Kind regards

    robert

4

Robert Klemme wrote:

ts wrote:

"D" == Damphyr <damphyr@freemail.gr> writes:

I do something like the following

Try something like this

moulon% cat b.rb
#!/usr/bin/ruby
class Test
  def self.open
     tt = new
     yield tt
  ensure
     tt.close if tt
  end

  def close
  end
end

module SomeModule
  def some_module_method
     puts "some_module_method"
  end
end

class DerivedTest<Test
  include SomeModule
end

DerivedTest.open{|tt|
  tt.some_module_method
}
moulon%

moulon% ./b.rb
some_module_method
moulon%

Guy Decoux

Guy, you were too fast again! :slight_smile: So I cut out my similar example and
just add what would have been my explanation:

The trick is not to do Test.new but to use just new (calls self.new which
is DerivedTest in sub class).

Kind regards

    robert

I can always rely on Guy for a fast answer :).
Simple, when not very obvious. I guess I had to keep in mind that new is private and for private methods self. is implicit.
Thanks guys,
V.-

···

--
http://www.braveworld.net/riva

____________________________________________________________________
http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ.
http://www.freemail.gr - free email service for the Greek-speaking.

5

Damphyr wrote:

Guy, you were too fast again! :slight_smile: So I cut out my similar example
and just add what would have been my explanation:

The trick is not to do Test.new but to use just new (calls self.new
which is DerivedTest in sub class).

Kind regards

    robert

I can always rely on Guy for a fast answer :).

:-))

Simple, when not very obvious. I guess I had to keep in mind that new
is private and for private methods self. is implicit.

new is *not* private - initialize is. How else could you do Foo.new? new
is a method of the class intance and initialize is an instance method.

Kind regards

    robert

6

Robert Klemme wrote:

Damphyr wrote:

Guy, you were too fast again! :slight_smile: So I cut out my similar example
and just add what would have been my explanation:

The trick is not to do Test.new but to use just new (calls self.new
which is DerivedTest in sub class).

Kind regards

   robert

I can always rely on Guy for a fast answer :).

:-))

Simple, when not very obvious. I guess I had to keep in mind that new
is private and for private methods self. is implicit.

new is *not* private - initialize is. How else could you do Foo.new? new
is a method of the class intance and initialize is an instance method.

Forget even that I said it. It was too late after too many beers :slight_smile:
V.-

···

--
http://www.braveworld.net/riva

____________________________________________________________________
http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ.
http://www.freemail.gr - free email service for the Greek-speaking.

7

Damphyr wrote:

Robert Klemme wrote:

Damphyr wrote:

Guy, you were too fast again! :slight_smile: So I cut out my similar example
and just add what would have been my explanation:

The trick is not to do Test.new but to use just new (calls self.new
which is DerivedTest in sub class).

Kind regards

   robert

I can always rely on Guy for a fast answer :).

:-))

Simple, when not very obvious. I guess I had to keep in mind that
new is private and for private methods self. is implicit.

new is *not* private - initialize is. How else could you do
Foo.new? new is a method of the class intance and initialize is an
instance method.

Forget even that I said it. It was too late after too many beers :slight_smile:

<sonorous voice>don't drink and code</sonorous voice>

:slight_smile:

    robert

8

Robert Klemme wrote:

Damphyr wrote:

Robert Klemme wrote:

Damphyr wrote:

snip

Simple, when not very obvious. I guess I had to keep in mind that new is private and for private methods self. is implicit.

new is *not* private - initialize is. How else could you do Foo.new? new is a method of the class intance and initialize is an instance method.

Forget even that I said it. It was too late after too many beers :slight_smile:

<sonorous voice>don't drink and code</sonorous voice>

The thing is, I woke up today and the first thing I thought was: "&§$&! that phrase about new is soooo wrong. What was I thinking?"
So the moral of the story is:
Don't drink and post.

If you code then you can always run your (ever present) unit tests and catch it later (there's always a second chance). No way to avoid public humiliation if you post though :slight_smile:
V.-

···

--
http://www.braveworld.net/riva

____________________________________________________________________
http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ.
http://www.freemail.gr - free email service for the Greek-speaking.

9

Robert Klemme wrote:

<sonorous voice>don't drink and code</sonorous voice>

Seriously, drinking and coding is a great combination. It made a lot of my programming assignments in college worth doing.

Devin

10

Yeah, but then you end up with a lot of variable names like 'sausage' and 'bratwurst' and 'bun', which all seemed hilarious and vaguely appropriate at the time, but which make no sense one week later.

Not that I have any experience with that.

···

On Sep 29, 2005, at 6:24 AM, Devin Mullins wrote:

Robert Klemme wrote:

<sonorous voice>don't drink and code</sonorous voice>

Seriously, drinking and coding is a great combination. It made a lot of my programming assignments in college worth doing.

11

Obviously they were approximations to chunky_bacon :slight_smile:

martin

···

Gavin Kistner <gavin@refinery.com> wrote:

On Sep 29, 2005, at 6:24 AM, Devin Mullins wrote:
> Robert Klemme wrote:
>> <sonorous voice>don't drink and code</sonorous voice>
> Seriously, drinking and coding is a great combination. It made a
> lot of my programming assignments in college worth doing.

Yeah, but then you end up with a lot of variable names like 'sausage'
and 'bratwurst' and 'bun', which all seemed hilarious and vaguely
appropriate at the time, but which make no sense one week later.