Re: Scope problem (?) in implementing Design Patterns in Ruby

On May 12, 9:56=A0pm, David Jacobs <[e-mail]> wrote:
> Hi Richard,
>
> Happy to help.
>
> I would definitely encourage you to not only look at design patterns (whi=
ch are okay, but often overkill or already built in to Ruby) but also to Ru=
by's standard features to reduce code errors.
>
> Ruby is a rich language. It has a lot of really well-crafted methods that=
 take care of a most of the tedium of coding, and for that reason the stand=
ard library is well worth learning.
>
> For example, in your code, instead of importing 'find' and using it to lo=
ok at directories, use Ruby's built-in Dir module. Dir['**/*'] will get you=
 all subdirectories and files recursively.
>
> Second, look into higher order functions. They let you change code from t=
his:
>
> def evaluate(dir, arg)
> results =3D []
> Dir['**/*'].each do |p|
> next unless File.file? p
> name =3D File.basename(p)
> case arg
> when String
> results << p if File.fnmatch(@arg, name)
> when Regexp
> results << p if @arg.match(name)
> end
> end
> results
> end
>
> Into this:
>
> def match?(str_or_re, file)
> str_or_re.is_a?(String) ? File.fnmatch(str_or_re, file) : str_or_re =3D~ =
file
> end
>
> def evaluate(dir, arg)
> Dir['**/*'].select {|f| File.file?(f) and match?(arg, f) }
> end
>
> Any time you see this pattern ...
>
> my_temporary_variable =3D []
>
> my_collection.each do |elem|
> my_temporary_variable << elem if some_condition
> end
>
> return my_temporary_variable
>
> .. you know that higher order functions would probably be a better soluti=
on. :)
>
> Hope that helps, and good luck learning this beautiful language.
>
> Cheers,
> David
>
> Any time you see this pattern in your code, you should automatically thin=
k
>
>
>
>
>
>
>
> On Thursday, 12 May 2011 at 12:00 pm, RichardOnRails wrote:
> > Hi 7Zip and David,
>
> > Thanks very much to you both for hanging in there with me.
>
> > I hacked up a working version (agnostic for 1.8.6/1.9.2) here:
> >http://www.pastie.org/1893405,
> > with results here:http://www.pastie.org/1893420
>
> > I apologize for having screwed a Pastie URL last time.
>
> > I left comments in code for the hacks I made. When I first
> > encountered the problem, I made a feeble attempt at prefixing :: for
> > All but I failed to take note of the fact that the All definition was
> > subordinate to Expression. That was stupid on my part, but I blame it
> > on the fact that I'm 77, have been retired from programming for 7
> > years and have only got serious about learning Ruby/Rails about a year
> > ago. It's been a struggle; I used to be faster on the uptake.
>
> > BTW, David Black has a very nice exposition of lookup for methods and
> > classes on page 98 et seq of his "The Well-Grounded Rubyist", one of
> > my "bibles".
>
> > I don't know how my hacks will playout for the parsing scheme in
> > "Design Patterns in Ruby". I going to follow it until this newsgroup
> > and/or I discover it's a fool's errand.
>
> > With my very best wishes to you both and thanks for your generous
> > insights,
> > Richard

Hi Dave,

I checked out your Version 2.  Added puts stuff and restriction to
names of files, which should probably be another one of your methods
instead of my hard-coding.
Expanded code: http://www.pastie.org/1895917
Output: http://www.pastie.org/1895932

I have only one question: I put a space between the & and the method
following it; the code broke.  Is the construct you used documented on-
line somewhere?  I've peeked at lambda documentation so I've got the
drift but I haven't used it in any of my code so far.

I copied your memo on the approach and plan to review it and use/
expand your code after I finish getting Russ Olson's code working or
giving up on it.  To his credit,  he posted his code on-line so I can
avoid typos and he included an apparently thorough set of unit tests.
So I've got a lot of studying to do.

Again,  thanks for your guidance and great ideas,
Richard