On Tue, 13 Mar 2001, W. Kent Starr wrote:

> "Best practice" IMO would be to use weirdo variable names within Procs that 
> have little possibility of stepping over your variables names at the next 
> level up, _unless_ that is _desired_ behavior, in which case I document it as 
> such, so _you_ can make a choice.

While I understand your point of view, and agree with the basic idea I
think I'm not supporting it.

I think all the code should born equal, and live it's life alltogerher as
equal as possible. (Well, not all, but this is a good simplificative
assertion. :)

I like idea of having the code "movable". Meaning the naming is systematic
through the code base, thus it's easy to grab code from a proc and turn it
into a method. If _special_naming_is_needed I additionally to cut&paste
have to rename all variables. That does not improve code free
movement. And we all know the code has it's own mind and does whatever it
pleases so we shouldn't try to stop it, but instead listen to it and give
it hints where to settle for the happy rest of it's life. ;-)

> Messing with the core in Ruby for this case IMO is _not_ wise. Like I said, 
> sometimes the stepping over variables names is _desirable_ behavior, as long 
> as _you_ are aware of that possibility and _you_ make that choice.

In this case, it seems we should go on and adjust the core. But only 
if it's needed. What's the best way to do it, and if it suits the language
at all is under good debate and I'm sure matz will have his good own
impression in the end.

> At any rate, that is how I view it now; I am up to being persuaded otherwise 
> :-)

Great! So I tried with "stylistic" and "code's speaking" arguments. Dunno
whether I succeeded. I'm certainly not up to start proposing the ways to
implement the change, so I'm just watching it with great curiosity.

	- Aleksi