ara.t.howard wrote:
> the very real problem with this sort of thing is that exceptions will
> map to one fugly line, making debugging for some poor soul a
> nightmare.  imagine that 'guess_extension' returned nil, or
> 'transform2' for that matter.  this kind of golfing is great for
> perl, but i've found over many painful experiences that it offers
> little in the way of clarity or maintainability in production code.
> i think at least a few ruby hackers, hardened by sunday night
> debugging sessions, and anyone fleeing perl, will agree that
> something along the lines of
> 
>    guesses = stems.map{|stem| "#{ stem }.#{ guess_extension stem }"}
>    basenames = transform2 source_files + transform1(guesses)
>    expanded = basenames.map{|basename| File.join dir basename}
> 
> is clear, maintainable, and easy to understand even if you don't
> dream of lambda calculus.  come back six months later and add
> transform3 and you'll appreciated what i'm talking about
> 
> and of course this isn't even addressing the issue that anyone
> *really* naming a function transform1 or transform2 should be
> smothered in their sleep, nor the fact that such functionality
> should, in something as beautiful as ruby, end up looking like
> 
>    filelist = Filelist.for source_files, :stems => stems, :dir => dir

*claps* Beautiful. Absolutely beautiful.

At first I dug what the OP was talking about with #as and also found it 
a bit odd that it wasn't a "slam dunk" for others.

But Ara's examples explain _why_ there was no slam dunk. #as is cool, 
but Ara's suggestions are simply good programming.

If I had to choose between any of the examples given (whether OP, JEII, 
etc.) I'd go with what Ara has put forth.

Off-topic, are there any Smalltalkers here who feel there's a boundary 
between object-oriented programming and functional programming? Can the 
two (do the two) coexist?
-- 
Posted via http://www.ruby-forum.com/.