# Inherited behaviour **URL:** \ **Category:** ruby-talk\ **Created:** [1 May 2008 09:20 UTC](https://rubytalk.org/t/inherited-behaviour/46226 "2008-05-01T09:20:10Z")\ **Posts on this page:** 8\ **Page:** 1

**Author:** ![Peter\_Morris](https://avatars.discourse-cdn.com/v4/letter/p/a8b319/32.png) [@Peter\_Morris](https://rubytalk.org/u/Peter_Morris)\ **Post date:** [1 May 2008 09:20 UTC](https://rubytalk.org/t/inherited-behaviour/46226/1 "2008-05-01T09:20:10Z")

Folks, would there be any DOWNSIDE to the call to the parents INHERITED method being deferred from the start to the end of the definition of the subclass? At the moment if you... class A def self.inherited klass end end class B \< A # this is point (1) def self.some\_method end end # this is point (2) at point (1), the inherited call on A happens. Now, what I want to know is.... would there be a problem if this was deferred to point(2) if you DID do that, then you could do interesting things inside inherited... class A def self.inherited klass do\_something\_interesting if klass.respond\_to?(:some\_method) end end Just a thought. ---

**Author:** ![David\_A\_Black1](https://avatars.discourse-cdn.com/v4/letter/d/bcef8e/32.png) [@David\_A\_Black1](https://rubytalk.org/u/David_A_Black1)\ **Post date:** [1 May 2008 12:21 UTC](https://rubytalk.org/t/inherited-behaviour/46226/2 "2008-05-01T12:21:38Z")

Hi -- > Folks, would there be any DOWNSIDE to the call to the parents INHERITED method being deferred from the start to the end of the definition of the subclass? > > At the moment if you... > > class A > def self.inherited klass > end > > class B \< A # this is point (1) > def self.some\_method > end > end # this is point (2) > > at point (1), the inherited call on A happens. > Now, what I want to know is.... would there be a problem if this was deferred to point(2) > > if you DID do that, then you could do interesting things inside inherited... > > class A > def self.inherited klass > do\_something\_interesting if klass.respond\_to?(:some\_method) > end It would introduce a kind of strange disjunction between the method name and the order of execution 🙂 I don't think "inherited" would be the right name any more. Also, consider this: module SomeModule def x end end class A def inherited(c) c.extend(SomeModule) end end class B \< A x end There are definitely things you can and can't do, given either scenario. I think having the inherited hook be triggered upon the event of inheritance makes the most sense. David > **···** > > On Thu, 1 May 2008, Peter Morris wrote: > > -- > Rails training from David A. Black and Ruby Power and Light: > INTRO TO RAILS June 9-12 Berlin > ADVANCING WITH RAILS June 16-19 Berlin > INTRO TO RAILS June 24-27 London (Skills Matter) > See [http://www.rubypal.com](http://www.rubypal.com) for details and updates! ---

**Author:** ![Joel\_VanderWerf1](https://avatars.discourse-cdn.com/v4/letter/j/94ad74/32.png) [@Joel\_VanderWerf1](https://rubytalk.org/u/Joel_VanderWerf1)\ **Post date:** [1 May 2008 16:32 UTC](https://rubytalk.org/t/inherited-behaviour/46226/3 "2008-05-01T16:32:43Z")

Peter Morris wrote: > Folks, would there be any DOWNSIDE to the call to the parents INHERITED method being deferred from the start to the end of the definition of the subclass? > > At the moment if you... > > class A > def self.inherited klass > end > end > > class B \< A # this is point (1) > def self.some\_method > end > end # this is point (2) > > at point (1), the inherited call on A happens. > Now, what I want to know is.... would there be a problem if this was deferred to point(2) Ruby classes are never closed, so there is no significant point (2), just an arbitrary snapshot in the continuing definition of class B. > **···** > > -- > vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 ---

**Author:** ![Yossef\_Mendelssohn](https://avatars.discourse-cdn.com/v4/letter/y/f19dbf/32.png) [@Yossef\_Mendelssohn](https://rubytalk.org/u/Yossef_Mendelssohn)\ **Post date:** [1 May 2008 20:20 UTC](https://rubytalk.org/t/inherited-behaviour/46226/4 "2008-05-01T20:20:45Z")

> Peter Morris wrote: > \> Folks, would there be any DOWNSIDE to the call to the parents INHERITED > \> method being deferred from the start to the end of the definition of the > \> subclass? > > \> At the moment if you... > > \> class A > \> def self.inherited klass > \> end > \> end > > \> class B \< A # this is point (1) > \> def self.some\_method > \> end > \> end # this is point (2) > > \> at point (1), the inherited call on A happens. > \> Now, what I want to know is.... would there be a problem if this was > \> deferred to point(2) > > Ruby classes are never closed, so there is no significant point (2), > just an arbitrary snapshot in the continuing definition of class B. There's only one inheritance point for a class, though. That the class isn't closed doesn't even enter into it. It's not like you can change the inheritance later on. Consider the following: class B \< A # some stuff end class B \< A # reopening with explicit parent, fine # more stuff end class B # reopening without parent, fine # more stuff end class B \< C # reopening with explicit parent, no good since the parent is different # more stuff end In this case, the "significant point (2)" would be the first 'end' in this example, the one immediately following the "some stuff" comment. > **···** > > On May 1, 11:32 am, Joel VanderWerf \ wrote: > > > -- > > vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 > > -- > -yossef ---

**Author:** ![David\_A\_Black1](https://avatars.discourse-cdn.com/v4/letter/d/bcef8e/32.png) [@David\_A\_Black1](https://rubytalk.org/u/David_A_Black1)\ **Post date:** [1 May 2008 20:37 UTC](https://rubytalk.org/t/inherited-behaviour/46226/5 "2008-05-01T20:37:05Z")

Hi -- > **···** > > On Fri, 2 May 2008, Yossef Mendelssohn wrote: > > > On May 1, 11:32 am, Joel VanderWerf \ wrote: > > > > > Peter Morris wrote: > > > > > > > Folks, would there be any DOWNSIDE to the call to the parents INHERITED > > > > method being deferred from the start to the end of the definition of the > > > > subclass? > > > > > > > At the moment if you... > > > > > > > class A > > > > def self.inherited klass > > > > end > > > > end > > > > > > > class B \< A # this is point (1) > > > > def self.some\_method > > > > end > > > > end # this is point (2) > > > > > > > at point (1), the inherited call on A happens. > > > > Now, what I want to know is.... would there be a problem if this was > > > > deferred to point(2) > > > > > > Ruby classes are never closed, so there is no significant point (2), > > > just an arbitrary snapshot in the continuing definition of class B. > > > > There's only one inheritance point for a class, though. That the class > > isn't closed doesn't even enter into it. It's not like you can change > > the inheritance later on. Consider the following: > > > > class B \< A > > # some stuff > > end > > > > class B \< A # reopening with explicit parent, fine > > # more stuff > > end > > > > class B # reopening without parent, fine > > # more stuff > > end > > > > class B \< C # reopening with explicit parent, no good since the > > parent is different > > # more stuff > > end > > > > In this case, the "significant point (2)" would be the first 'end' in > > this example, the one immediately following the "some stuff" comment. > > That seems very arbitrary, though, in the sense that the superclass's > business with the subclass has no more to do with methods defined the > first time the class is opened than with any others. > > David > > -- > Rails training from David A. Black and Ruby Power and Light: > INTRO TO RAILS June 9-12 Berlin > ADVANCING WITH RAILS June 16-19 Berlin > INTRO TO RAILS June 24-27 London (Skills Matter) > See [http://www.rubypal.com](http://www.rubypal.com) for details and updates! ---

**Author:** ![Yossef\_Mendelssohn](https://avatars.discourse-cdn.com/v4/letter/y/f19dbf/32.png) [@Yossef\_Mendelssohn](https://rubytalk.org/u/Yossef_Mendelssohn)\ **Post date:** [5 May 2008 15:10 UTC](https://rubytalk.org/t/inherited-behaviour/46226/6 "2008-05-05T15:10:18Z")

It is arbitrary, but it makes sense if the method is called 'inherited'. Really, I agree that it work the way it does now, when the inheritance actually happens. If something has to happen at a different point, it should be a different callback that does it. > **···** > > On May 1, 3:37 pm, "David A. Black" \ wrote: > > > Hi -- > > > > On Fri, 2 May 2008, Yossef Mendelssohn wrote: > > \> On May 1, 11:32 am, Joel VanderWerf \ wrote: > > \>\> Peter Morris wrote: > > \>\>\> Folks, would there be any DOWNSIDE to the call to the parents INHERITED > > \>\>\> method being deferred from the start to the end of the definition of the > > \>\>\> subclass? > > > > \>\>\> At the moment if you... > > > > \>\>\> class A > > \>\>\> def self.inherited klass > > \>\>\> end > > \>\>\> end > > > > \>\>\> class B \< A # this is point (1) > > \>\>\> def self.some\_method > > \>\>\> end > > \>\>\> end # this is point (2) > > > > \>\>\> at point (1), the inherited call on A happens. > > \>\>\> Now, what I want to know is.... would there be a problem if this was > > \>\>\> deferred to point(2) > > > > \>\> Ruby classes are never closed, so there is no significant point (2), > > \>\> just an arbitrary snapshot in the continuing definition of class B. > > > > \> There's only one inheritance point for a class, though. That the class > > \> isn't closed doesn't even enter into it. It's not like you can change > > \> the inheritance later on. Consider the following: > > > > \> class B \< A > > \> # some stuff > > \> end > > > > \> class B \< A # reopening with explicit parent, fine > > \> # more stuff > > \> end > > > > \> class B # reopening without parent, fine > > \> # more stuff > > \> end > > > > \> class B \< C # reopening with explicit parent, no good since the > > \> parent is different > > \> # more stuff > > \> end > > > > \> In this case, the "significant point (2)" would be the first 'end' in > > \> this example, the one immediately following the "some stuff" comment. > > > > That seems very arbitrary, though, in the sense that the superclass's > > business with the subclass has no more to do with methods defined the > > first time the class is opened than with any others. > > > > David > > > > -- > > Rails training from David A. Black and Ruby Power and Light: > > INTRO TO RAILS June 9-12 Berlin > > ADVANCING WITH RAILS June 16-19 Berlin > > INTRO TO RAILS June 24-27 London (Skills Matter) > > Seehttp://www.rubypal.comfor details and updates! > > -- > -yossef ---

**Author:** ![Macario\_Ortega](https://avatars.discourse-cdn.com/v4/letter/m/cdc98d/32.png) [@Macario\_Ortega](https://rubytalk.org/u/Macario_Ortega)\ **Post date:** [29 October 2008 07:28 UTC](https://rubytalk.org/t/inherited-behaviour/46226/7 "2008-10-29T07:28:14Z")

Yossef Mendelssohn wrote: > > \>\>\> end # this is point (2) > > \> the inheritance later on. Consider the following: > > \> # more stuff > > That seems very arbitrary, though, in the sense that the superclass's > > Seehttp://www.rubypal.comfor details and updates! > > It is arbitrary, but it makes sense if the method is called > 'inherited'. Really, I agree that it work the way it does now, when > the inheritance actually happens. If something has to happen at a > different point, it should be a different callback that does it. Hi, I have this situation where it would save me some typing if the inherited callback was called after the class was fully defined (with all its methods). is there a way I can get "yeah!" instead of "damn!"? class A def self.inherited(klass) p klass.respond\_to?(:my\_method) ? "yeah!" : "damn!" end end class B \< A def self.my\_method end end p "too late!" if B.respond\_to?(:my\_method) thanks! > **···** > > > On May 1, 3:37 pm, "David A. Black" \ wrote: > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---

**Author:** ![Brian\_Candler](https://avatars.discourse-cdn.com/v4/letter/b/5f9b8f/32.png) [@Brian\_Candler](https://rubytalk.org/u/Brian_Candler)\ **Post date:** [29 October 2008 12:26 UTC](https://rubytalk.org/t/inherited-behaviour/46226/8 "2008-10-29T12:26:14Z")

Macario Ortega wrote: > Hi, I have this situation where it would save me some typing if the > inherited callback was called after the class was fully defined (with > all its methods). But it's never "fully defined", as it can be extended at any time in the future. (Or depending on how you look at it, it's "fully defined" at the instant the subclass is created, before any methods are added to it) > is there a way I can get "yeah!" instead of "damn!"? class Class alias :old\_new :new def new(parent = Object, &blk) child = old\_new(parent, &blk) parent.delayed\_inherited(child) if parent.respond\_to?(:delayed\_inherited) child end end class A def self.delayed\_inherited(klass) p klass.respond\_to?(:my\_method) ? "yeah!" : "damn!" end end B = Class.new(A) do def self.my\_method end end p "too late!" if B.respond\_to?(:my\_method) ### Or you could just trigger it explicitly: class Class def ok return unless superclass.respond\_to?(:delayed\_inherited) superclass.delayed\_inherited(self) end end class A def self.delayed\_inherited(klass) p klass.respond\_to?(:my\_method) ? "yeah!" : "damn!" end end class B \< A def self.my\_method end ok end p "too late!" if B.respond\_to?(:my\_method) ### That's only two characters to type for each class definition 🙂 > **···** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C).