From: Bill Guindon <agorilla@...>
Date: 2004-09-20T09:59:47+09:00
Subject: Re: Method improvement request .--

On Mon, 20 Sep 2004 07:24:29 +0900, Charles Hixson
<charleshixsn@earthlink.net> wrote:
 
> Bill Guindon wrote:

> >Might be easier if you could show a sample of what you're starting
> >with, and what you'd like it to become.  If the sample is large, you
> >can always paste it into codepaste (http://www.codepaste.org), and
> >just put the link to it in the email

> >Also... I think parse2 and parse3 can be combined into something like this:
> >
> >    p2 = p1.split(/(\.\.\.|--)/)
> >    p2.delete('--')
> >    p2.delete('...')
> >    p2.each {|p3| yield p3}
> >

> OK, I've copied it over to codepaste here:
> http://www.codepaste.org/paste/comment/218
> http://www.codepaste.org/view/paste/163?show_comments=1
> etc.
> (How long does code stay up here?  I never knew the site existed.)

New site, written in Ruby.  For now, there's no time limit.

I was bored with my own stuff, so trimmed down the 'run' a bit...
http://www.codepaste.org/view/paste/163?show_comments=1

Hope it still runs, couldn't test it for lack of the 'word' file you required.
There are links on the right to see the originals, and a diff between the two.
 
> But I think that I put the relevant pieces in the first e-mail.
> However,   I don't intend that elipsis and double-dashes be deleted.
> They merely need to be parsed separately from the words that they appear
> with.  They do contain significant meaning, so merely deleting them
> would be anti-productive.

Right, much easier to understand what you seek now.  Sounds like
you're looking at a text formatter, I'm guessing for printing.

> Also:    Is
> 
>   chunk = [] << chunk
>   chunk.flatten!
>   return chunk
> better in some way than
>   return "" unless chunk.respond_to?("[]")

Depends on whether you want to stay, or return.  The first forces the
Array so you'll stick around and process whatever you have -- useful
for processing when you're not sure if you were given an Array or a
String.

The second bails out, so is the better choice if you don't want to
look at it unless it's an Array.

> I could see, perhaps,
>   return "" if not chunk or chunk.empty?
> but I'd been reading that it was more Ruby-esque to use duck typing and the responds_to? test.  That's one reason I didn't do
>   return "" if chunk.nil?

Actually, checking for Nil would fall into duck typing (as far as I
understand it).  Anything can be Nil, so it's not quite the same as
explicit type checking.
 
> And I'm still not certain what I should really be doing in such a case. What I really want to do is avoid returning nil.  I want to skip over the processing of this case without aborting the calling process (likely an each).  If this were a loop, then the command would be next rather than break or retry.

I'd go with ...  return '' if not chunk  
or...  return unless chunk

but that's just a personal preference.

With a bit of time, the 'nil' bugs will go away, or at least have
semi-obvious solutions.

-- 
Bill Guindon (aka aGorilla)