Mariusz Pekala
6/20/2007 1:32:00 PM
On 2007-06-20 07:37:14 +0900 (Wed, Jun), Daniel Martin wrote:
> On the other hand, I find the idea that the scoping and binding of
> variables could change based on the particular code path followed at
> run time a horribly non-intuitive concept, since I think of "variable
> scope" as something as static as the code itself - that is, you should
> only be able to screw with variable scoping by strange
> meta-programming tricks.
Maybe I don't understand something, but the decision whether something
is a variable or is a method call is based not on the code executed
(which is hard to predict when reading the source) but on the code
parsed, which is pretty static.
def this_method( x )
p y # This 'y' will always be a method call.
# (even if you call this_method again)
if x
y = 1 # because of this line in the source code...
end
p y # ...this 'y' will always be a variable.
end # ..independent on the value of x
So, I would (IMHO) assume, that this is not bad-black-magic, but
good-and-understandable-white-magic aspect of ruby.
The confision may emerge when the block of code has many lines, hard to
grasp in one eye shot, but I have been taught that if you write a
function that is longer than half of your editor window you should
extract part of it into another function.
With short blocks it is harder to mistake a method for a variable.
P.S.:
If someone still does not like this magic behaviour, assume that it
saves you from writing:
def this_method( x )
p y
if x
#pragma set_as_variable(y) /* and if you forgot, you will get parse-error */
y = 1
end
p y
end
;-)
--
No virus found in this outgoing message.
Checked by 'grep -i virus $MESSAGE'
Trust me.