From: RichardOnRails <RichardDummyMailbox58407@...>
Date: 2011-05-13T16:31:27+09:00
Subject: Re: Scope problem (?) in implementing Design Patterns in Ruby

On May 12, 9:56 pm, David Jacobs <develo...@wit.io> wrote:
> Hi Richard,
>
> Happy to help.
>
> I would definitely encourage you to not only look at design patterns (which are okay, but often overkill or already built in to Ruby) but also to Ruby'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 standard library is well worth learning.
>
> For example, in your code, instead of importing 'find' and using it to look 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 this:
>
> def evaluate(dir, arg)
> results = []
> Dir['**/*'].each do |p|
> next unless File.file? p
> name = 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 =~ 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 = []
>
> 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 solution. :)
>
> Hope that helps, and good luck learning this beautiful language.
>
> Cheers,
> David
>
> Any time you see this pattern in your code, you should automatically think
>
>
>
>
>
>
>
> 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