From: Robert Klemme <shortcutter@...>
Date: 2009-03-17T20:07:33+09:00
Subject: Re: Dynamically extending modules once they have been included

On 17.03.2009 11:11, James Coglan wrote:
> [Note:  parts of this message were removed to make it a legal post.]
> 
> 2009/3/17 Synth <librarising@gmail.com>
> 
>> I get it now...the ancestors list of the module is copied over to the
>> including class at "include-time".  If the module's ancestry is
>> changed, this will not be reflected.   This seems to me to inhibit
>> some "meta-programmability"(if that's a word) as you can't mixin
>> modules to already included modules and have the effect take place
>> with whomever has already included the module.  In other words, its
>> not consistent with the ability to dynamically change(add/change/
>> delete) methods of the module directly at runtime.
> 
> This is very surprising, I always thought the ancestor tree was inspected at
> method call time,

That's true, but the point made was that it is _built_ on inclusion time.

> IMO this could be done better and preserve a bit more dynamism.

> Would be interested to hear other people's thoughts on this. It's kind of an
> edge case, but my opinion is that this behaviour is contrary to much of
> Ruby's dynamism, and is inconsistent: if you add methods to M, they become
> available to C, so why not new ancestors? Also, it means the ancestry tree
> looks different depending on who you ask. Having said that, experience tells
> me that "fixing" it would introduce a serious performance overhead for the
> whole language.

More than that: existing code may be broken.  There are good reasons not 
to "fix" this, because otherwise a change of a module has a side effect 
on a totally different class.  I cannot remember having seen this 
discussed in the last years (which does not necessarily mean something) 
but I doubt that many people see this as limitation.

My question for Pete would be: why do you need this and do you need this 
frequently?  Maybe there is a design pattern issue - i.e. a programming 
problem that can be solved differently - maybe even better.

Btw, you can create a "fix" with some metaprogramming.  With methods 
Module#included and Class#inherited it should be possible to reinclude 
the changed module in all classes that have it included.

Given that, the infrequency of this issue surfacing and the unknown risk 
of change I vote for "no change".

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end