Re: Dynamically extending modules once they have been included

In my case, I suppose, I was being a bit *lazy*, but I could say I was
being extensible too.  I didn't really need the dynamism that this use
case points to.  To be specific, I am building an extension to the
Runt Gem.  Runt is a ruby gem to model Martin Fowler's Temporal
Expression design pattern.  The way its currently coded is that you
have concrete expression classes like DIWeek(Day in Week) or REYear
(Range Each Year) and some of these classes mixes in a TExpr module.
The set of expression classes is finite.  In my extension to Runt, I
need to add some behavior to the TExpr module which I do with another
mixin.  I didn't want to have to worry about which classes mixin the
TExpr, I just wanted to modify(aka extend) the TExpr module like you
would any ordinary class and have it be reflected in all classes who
included this module.  The alternative(which is what I'm ending up
doing) is to loop through all the classes of Runt and check the
ancestors for TExpr and if so, include my extension module directly
into the class.  This approach seems yucky to me and not in the spirit
of ruby and really OO design.

You can clearly argue with me whether you think extending a module
with another is appropriate or not in the above case.  However, the
issue remains that this behavior is not consistent with the rest of
ruby.  I point again to the fact that you can change behavior of a
module directly and it will be reflected by all included classes -
however NOT if you change behavior via including another module.

Also, I don't necessarily(keyword here) agree with the philosophical
point of needing 'a lot' of use cases to implement a feature. This is
a contentious issue, I know, but I think the ability to dynamically
alter code at runtime speaks for itself.  Then combine this with the
fact that you can modularize this dynamic code, it seems common sense
to me.  I mean, that's the beauty of ruby and the whole point of
mixins.  You can bundle up code that you can inject into objects at
runtime.  But why can't you do this if the target of your injection is
another module?  I'm definitely surprised this is not more talked about
(and criticized :) )

As far as changing this behavior, I'd be curious as to some current
ruby code that would break if the ancestor tree was more dynamic to
accomplish this behavior.  I think a weighted number of use cases that
would break should be compared with a weighted number of use cases
that could be enabled(and I personally think "modular
metaprogrammability" has a huge amount of gravity! :) )

> Good point! =A0Still the question remains, how often is this used and who
> would benefit from that change (and what is the price)?
>
> Cheers
>
> =A0 =A0 =A0 =A0 robert
>
> --
> remember.guy do |as, often| as.you_can - without end