inherited behaviour.

[Peter Morris]

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.

 

[David A. Black]

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

 

[Joel VanderWerf]

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.

 

[Yossef Mendelssohn]

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.

 

[David A. Black]

Hi --

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!

 

[Yossef Mendelssohn]

Hi --











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.

 

[Macario Ortega]

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!

 

[Brian Candler]

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