extend quesion

[Phil Tomson]

The following doesn't quite do what I would expect:

module A
def foo
"A::foo"
end
end
module B
def foo
"B::foo"
end
end
class Demo
def to_a
self.extend(A)
end
def to_b
self.extend(B)
end
def initialize
self.extend(A)
end
end


d = Demo.new
puts d.foo #=> A::foo
d.to_b
puts d.foo #=> B::foo
d.to_a
puts d.foo #=> B::foo (but I expected A::foo)


OK, I can kind of see why this happended; B's foo 'hide's A's foo method. But
I'm not sure why it didn't happen in the second 'puts' above (ie. why
wouldn't it just keep printing A::foo every time?). I think the answer is that
A has already been mixed-in so it's not really mixed-in again (true?).


And how would I go about making this work so that it prints:

A::foo
B::foo
A::foo

?

Phil

 

[David Vallner]

D=C5=88a Streda 15 Febru=C3=A1r 2006 03:23 Phil Tomson nap=C3=ADsal:

I think the answer is that A has already been mixed-in so it's not really
mixed-in again (true?).=20

Quite so.

And how would I go about making this work so that it prints:

A::foo
B::foo
A::foo

?

Make the message printed an instance attribute and change it? *duck*

Mixins aren't plain supposed to do that. They are to add methods, not rewri=
te=20
them at whim. If you -have- to do this via metaprogramming, use singleton=20
methods. Especially in non-trivial code, heavy use of #extend to change=20
behaviour over and over again would get really messy.

David Vallner

 

[Phil Tomson]

D=C5=88a Streda 15 Febru=C3=A1r 2006 03:23 Phil Tomson nap=C3=ADsal:

Quite so.


Make the message printed an instance attribute and change it? *duck*

Mixins aren't plain supposed to do that. They are to add methods, not rewri=
te=20
them at whim.

Yeah, I just thought it would be a nice, fairly easy solution.

If you -have- to do this via metaprogramming, use singleton=20
methods.

Yeah, I could probably do something like that by redefining the method...

(BTW: Using extend as above makes foo a singleton method )

Especially in non-trivial code, heavy use of #extend to change=20
behaviour over and over again would get really messy.

The only way to really get it to work would be to remove_method before doing
the extend. The problem with that is that remove_method doesn't work in that
context (removing singleton methods).

I should probably consider some sort of delegation pattern instead. One
fairly easy way would be to use method_missing and then change the target
object of the message (though I want to avoid overuse of method_missing because
1) it can make things difficult to debug and 2) I might need it for another
purpose in this application. )

Phil

 

[Robert Klemme]

Yeah, I just thought it would be a nice, fairly easy solution.


Yeah, I could probably do something like that by redefining the
method...

Or use the strategy / state pattern.

(BTW: Using extend as above makes foo a singleton method )


The only way to really get it to work would be to remove_method
before doing the extend. The problem with that is that remove_method
doesn't work in that context (removing singleton methods).

I should probably consider some sort of delegation pattern instead.
One fairly easy way would be to use method_missing and then change
the target object of the message (though I want to avoid overuse of
method_missing because 1) it can make things difficult to debug and
2) I might need it for another purpose in this application. )

I think you can use SimpleDelegator and change the target in between.
Didn't test it myself though.

Kind regards

robert

 

[David Vallner]

D=C5=88a Streda 15 Febru=C3=A1r 2006 08:48 Phil Tomson nap=C3=ADsal:

The only way to really get it to work would be to remove_method before
doing the extend. The problem with that is that remove_method doesn't wo= rk
in that context (removing singleton methods).

Not even in the singleton class?

David Vallner

 

[Phil Tomson]

D=C5=88a Streda 15 Febru=C3=A1r 2006 08:48 Phil Tomson nap=C3=ADsal:

Not even in the singleton class?

I couldn't get it to work. Maybe there's some way.

However, I've come up with another way of doing what I was trying to do.
What I needed was a Simulation functionality (where the code is run) and a
Translation functionality (where the code translated to another language).
Since the user doesn't need to switch from one to the other in the same run it
makes sense to inherit from a different class based on a commandline
argument(or mixin a different module). something along the lines of this
very simplified example:

class A #could be modules too
def foo
"A::foo"
end
end
class B
def foo
"B::foo"
end
end

superclass = if ARGV[0] == "B"
B
else
A
end

class Demo < superclass
#could use include module instead of inheritance of superclass
end

d = Demo.new
puts d.foo

ruby demo.rb #=> A::foo (default)
ruby demo.rb B #=> B::foo

This should do what I want and it doesn't lead to extra calls as with
delegation/method_missing schemes which could slow things down
a little bit.

Phil

 

[David Vallner]

D=C5=88a =C5=A0tvrtok 16 Febru=C3=A1r 2006 01:33 Phil Tomson nap=C3=ADsal:

I couldn't get it to work. Maybe there's some way.

However, I've come up with another way of doing what I was trying to do.
What I needed was a Simulation functionality (where the code is run) and a
Translation functionality (where the code translated to another language).
Since the user doesn't need to switch from one to the other in the same r= un
it makes sense to inherit from a different class based on a commandline
argument(or mixin a different module).

I'll agree with Robert Klemme's previous post that you probably want to=20
delegate to a strategy in this case. Much less... well... weird. -And- you=
=20
can switch at your leisure too.

David Vallner

 

[Phil Tomson]

D=C5=88a =C5=A0tvrtok 16 Febru=C3=A1r 2006 01:33 Phil Tomson nap=C3=ADsal:

I'll agree with Robert Klemme's previous post that you probably want to=20
delegate to a strategy in this case. Much less... well... weird. -And- you=
=20
can switch at your leisure too.

Conditional inheritance considered weird?

At one point or another much of what we now consider common practice was
thought to be weird. ;-)

Phil

 

[David Vallner]

D=C5=88a =C5=A0tvrtok 16 Febru=C3=A1r 2006 20:23 Phil Tomson nap=C3=ADsal:

Conditional inheritance considered weird?

At one point or another much of what we now consider common practice was
thought to be weird. ;-)

By all means, play around with uncommon concepts. Except I'm more likely to=
=20
use established patterns that do the same. Matter of taste? Certainly. Up t=
o=20
the point where one way doesn't work and the other does - at the end of the=
=20
day, it's usefulness that matters.

In the specific case of doing so only once, conditional inheritance does=20
roughly what delegating to a strategy would. But in the first posted exampl=
e,=20
the latter approach gives you a few more points of flexibility that were=20
needed to achieve the expected behaviour.

Maybe there is a problem that is indeed most elegantly solved by runtime=20
conditional inheritance. Considering that delegation can technically replac=
e=20
inheritance, as seen in prototype-based OO programming languages, I=20
personally doubt it. But this wasn't such a problem.

David Vallner