Hi --

On Thu, 1 May 2008, 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)
>
> 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

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

-- 
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!