David A. Black wrote:
...stuff deleted...
Since integers are immutable (luckily!), and local variables are
local, you can't change an integer object via a reference copied to a
method. If it helps, I can assure you that you would *not* want this
to happen. It would be very weird if my local variables bindings were
at the mercy of methods that I called.
What you're really looking for is an object container, and local
variables don't really work that way. For container semantics you
really need to use containers. You could do something like:
First, thanks for the quick answer. That was unexpected.
Unfortunately I can't say I understand the part of your response I
quoted above, other than that it says, "Nope, you can't do what you're
trying to do. Unless you're working with strings, which are somehow
different."
The "local variables _bindings_" bit implies to me this has something to
do with Ruby's underlying storage that I have not yet grasped. I'm
still thinking of a 'local variable' as really some chunk of memory, and
the way the bits are set in that memory mean something in the context of
my program. If I pass that location to a subprogram, and know that it's
going to put something else in it, that's good.
I can think of examples where I would like my subprogram to modify the
local variables of the calling code. For instance, I have two points,
and I want to calculate m and b for the formula of a line, as in y = m *
x + b. I would be inclined to write a subprogram calc_m_b(x1, y1, x2,
y2, var m, var b) (in Pascalese). I could do what amounts to the same
thing with two functions, one returning m and the other b, but that
seems sort of silly in this case. I could design an object that
represented a line in some fashion, and let it hold m and b, but that's
not always what you'd want, either.
Maybe I'm not thinking in terms of objects enough yet?
Thanks again,
John