inherited behaviour.

Discussion in 'Ruby' started by Peter Morris, May 1, 2008.

  1. Peter Morris

    Peter Morris Guest

    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.
     
    Peter Morris, May 1, 2008
    #1
    1. Advertising

  2. 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!
     
    David A. Black, May 1, 2008
    #2
    1. Advertising

  3. 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
     
    Joel VanderWerf, May 1, 2008
    #3
  4. 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.

    > --
    > vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407


    --
    -yossef
     
    Yossef Mendelssohn, May 1, 2008
    #4
  5. 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!
     
    David A. Black, May 1, 2008
    #5
  6. 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!


    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.

    --
    -yossef
     
    Yossef Mendelssohn, May 5, 2008
    #6
  7. Yossef Mendelssohn wrote:
    > On May 1, 3:37 pm, "David A. Black" <> 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!
    --
    Posted via http://www.ruby-forum.com/.
     
    Macario Ortega, Oct 29, 2008
    #7
  8. 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 :eek:ld_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/.
     
    Brian Candler, Oct 29, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jim Schueler
    Replies:
    2
    Views:
    451
  2. :crp:
    Replies:
    0
    Views:
    613
    :crp:
    Jan 25, 2005
  3. Andy Chambers
    Replies:
    1
    Views:
    395
    Daniel Dyer
    May 14, 2007
  4. Richard Purchas

    Change in behaviour from framework version 1.1 to 2.0 for inherited textbox

    Richard Purchas, Feb 12, 2006, in forum: ASP .Net Building Controls
    Replies:
    0
    Views:
    140
    Richard Purchas
    Feb 12, 2006
  5. 7stud --
    Replies:
    11
    Views:
    426
    7stud --
    Nov 9, 2007
Loading...

Share This Page