Execpt now you’ve just changed A which could break anything else using
Actually I think J’s use of initialize, rather then some other method
was in a err. Yes? You can skip over ancestors using something like
facet/kernel/as but initialize is a touchy matter --it’s not something
one generally defines in a module in the first place.
Even so, if that’s really wha is wanted…
What does #as do? It get the UnboundMethod in B and binds it to C, and
offers it up in a nice little Functor. You can bypass the Functor if
you want with #send_as(B,:initialize).
# init for B here
You can use Module#included to handle class/module level
I sometimes wish there was a well-defined instance initialization
included modules instead of relying on the appropriate use of super()
initialize(). I’m not sure what it would look like though, maybe:
def initialize_M #initialization for M goes here
Presumably Class#new would trigger Module.instantiated for all
in some well defined order (appearence in ancestors list?).
These seems kind of inelegant though. There must be a better
solution. Or maybe
it is a solution looking for a problem.
def initialize; puts “From A”; end
#=> From B
#=> From A
This code essentially (or at least partially succeeds at) reversing the
inclusion order of two modules. Ie.
module B; end
module A; include B; end
module B; include A; end
Are you sure you want to do that? That can have crazy effects! In fact
it’s a very bad idea unless you have full control coding over these
modules, and if that’s the case you wouldn’t need to do it anyway. So
as I say, I’m highly suspect. Looking at exacly what this does it