> This hints at design flaws within your application.
I suspect this too, though I can't see a *convincing* better solution.
I try to sketch my problem in an abstract way:
I have a function f which, when receiving a Card object, can find a
certain integer number which it then uses for further calculation:
def f(a,b,c)
x=g(c) # c is a Card, x is a positive integer
... # do something with a, b, x
end
Occasionally, I am calling f in a loop, and I know from the context (I
could actually make this an assertion) that g(c) MUST be the same in
each iteration, even though the c is sometimes different. Hence I want
to precompute the value of g(c) and pass the integer to f.
If it were C++, I would implement this providing to overloaded
definitions of f.
As for Ruby, I see so far four possibilities:
(1) Query the type of c at runtime
(2) Require, that c is an integer, and calculate g(c) always at the
calling site, i.e. f(a,b,g(c))
(3) Provide two differently named functions, one expecting a Card and
one expecting an integer.
(4) Make g a method of Card, and add a g method to Fixnum, which just
returns the number unchanged.
I agree with you, that (1) is ugly, because we don't want to do runtime
tests.
I don't like (2) and (3) either, because it makes f more inconvenient to
use.
(4) has the advantage, that we can write inside f simply:
x=c.g
This would be duck typing at work, but extending such a basic class as
Fixnum by a function, which doesn't have any semantic on its own,
doesn't look like good design either.
What approach would you suggest?
Ronald