From: dflanagan@...
Date: 2007-01-20T05:10:10+09:00
Subject: Re: local variable assertion

Rob,

Yes, breaking long methods up is usually good.  If the smaller methods
that one is refactoring into are not of general utility, however, then
I would argue (perhaps in my JavaScript mindset) that they should not
be methods, but lambdas instead.    But re-factoring into lambdas
doesn't help with the local variable issue since you can never be
confident about the scope of your lambda parameters.

Isn't refactoring, in fact, one of the scenarios where you run into
problems with variable overlap?  If you cut-and-paste a block from one
method into another, and the new method uses a variable that has the
same names as one of the block parameters, you've just set yourself up
for trouble.

In don't like Perl, but I do think that Perl's "my" variables solve
this problem elegantly.

  David

On Jan 18, 11:05 pm, "Rob Sanheim" <rsanh...@gmail.com> wrote:
> On 1/19/07, dflana...@gmail.com <dflana...@gmail.com> wrote:
>
> > Funny wordwrapping of the code and comments in that post...
>
> > You can also see the code at my blog:
> >http://www.davidflanagan.com/blog/2007_01.html#000120
>
> >     DavidWithout diving too much into the implementation of this, I would say
> if you really find yourself needing it alot you should refactor to
> smaller methods that do less stuff.  I really find composed method and
> extract method are some of the most critical refactorings in Ruby.
>
> Oh yea, and welcome to Ruby =).  I'm sure you'll find a lot to love
> coming from the Javascript world.  There are some libraries that let
> you write prototype style Ruby similiar to idiomatic Javascript.
> 
> - Rob