From: "David A. Black" Date: 2008-05-02T05:37:05+09:00 Subject: Re: inherited behaviour. 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 for details and updates!