[ruby-talk:12538] Re: FEATURE REQUEST: 'my' local variables

On Monday 12 March 2001 11:17, Stephen White wrote:
> On Mon, 12 Mar 2001, W. Kent Starr wrote:

>   x = 5; loop {|y| _x = x + 5; loop {|y| puts _x } }
>
> Does the _x carry over from the parent loop?
>

the intention was:

x = 5
puts x -> 5
loop { |y| _x = x + 5; puts _x } -> 10
puts x -> 5


> In any event, I think the whole concept of block local variables is a
> solution in search of a significant problem.
>

Yes and no. The "problem" is not behavior within my own code or your own code.
_We_ can control that. The problem is me using your code and vice versa where 
we may use predefined loops with variables that step over each others next 
scope up variables. The point is, when _you_ use portions of my code, either 
as snippets (where you can see the problem) or as predefiend Procs (where you 
can still see, but with more study). Bottomline is that _you_ should be able 
to use my predined "cool" proc with no effort and still feel safe realative 
any of your variables in the next space up.   

> 200 line methods scream out more for a refactoring than a language
> extension. A beginning programmer is definitely going to get some
> things wrong, but providing a language extension to cater for this
> isn't going to help a lot. Their code is likely to be broken in more
> ways than just local variables.

Agreed. But that is not the problem I am looking; _my_ problem is safe code 
sharing w/o hassle or risk. We can educate the beginner re "best practices". 
But, w/o extra effort, can we safely share certain kinds of code? W/o effort 
is important...if I have to review your code before I use it, might I not be 
better off rewriting mu own? Just a though. :-)

> What if the beginning programmer opened a file inside one block and
> reads from it in other blocks in a fixed order? Moving the blocks
> around is still going to screw that up regardless of "my local"
> statements. What about GUI calls? Global variables?

Yes, yes, of course. I wasn't thinking of that, though. That can be cured by 
education (which on this list works very well, so far). 

> There's a lot of other problems in programming that are equally annoying.
> For example I would like to be able to change a method or variable name
> and have it automatically updated throughout the project. Can I have a
> language extension for that?

Why bother? Write a parser to do that. Or do you want it runtime? Embed a 
parser to do that :-)

> Ruby is clean because it only provides solutions for common problems.

I could not agree more! Which is why IMO we should concentrate on 
'conventions' and 'best practices' or well-forme _Ruby_ solutions, and look 
to modify core only as a last resort. During the past few months I have 
monitored this list I have seen genuine requests for valuable, needed 
'functionality' often expressed as an RFC at the _core_ level and have seen 
Dave, Dave, Ben, Guy, Kevin, yourself, and others (and of course, matz) offer 
viable working solutions _IN RUBY_ that do not require any change to the 
language. This IMO is a 'good' thing (and a testament to Ruby)

> Perl is messy because it provides solutions for minor problems.
> The more additions to Ruby, the more stuff I have to know before I
> understand Ruby, and the harder other people's programs become to read.

Perl does very well what it was designed originally to do. My interest in 
Perl began with a need to slice and dice string formatted data. I use to use 
dBase to do that; Perl was better :-)

Over time, people have added 'this' and 'that' to Perl, at core, to make it 
do anything and everything. Soem of that works, some hasn't. In some camps 
Perl has gotten a few black eyes because of this; but it wasn't Perl, it was 
the efforts to make Perl 'unPerl' that have cause this IMO. When I did 
one-onone therapy type stuff many years, people would come to me and say 'I 
really love my partner but if only I could make him/her change their behavior 
this way or that." And I would reply that what you 'love' is a 'whole, 
greater than the sum of its parts'. Change this part or that part in any 
significant way and you risk changing the 'whole' and you may not be so fond 
of the result.

It my be too late to return Perl to purity; but, as you say, Ruby is still 
'pure'. Personally, I think we should strive to keep it that way and make 
core changes _only_ when they are truly necessary (and truly advance the 
language) and not simply because it is a popular request.

Does anybody agree with this?

Regards,

Kent Starr
[e-mail]