From: "W. Kent Starr" Date: 2001-03-13T13:04:38+09:00 Subject: [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 elderburn@mindspring.com