Ruby on Rails

> 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

--
Posted via http://www.ruby-forum.com/.