Re: Ruby regex question

Dossy graced us by uttering:
> I'm mailing a follow-up to a mailing list, not replying to
> your mail.  The difference between "r" and "L" in mutt... ;-)

Hmm. I actually added those lines because a omitting them caused someone
on the python ML to stealth cc me.  Apparently _including_ them causes
those on the ruby-lang ML to stealth cc me?  Bummer.  I just use slrn;
then it's the difference between 'r' and 'f', almost always the latter.

> Is it typical to test values as they're set (when you execute the
> regex) or right before you use them?  What's the more defensive way of
> coding?

Well, depending on how many capturing groups you set up in the regex,
you can save yourself a lot of checking. eg, if you don't check the
success of the match, you end up having to check any number of $[1-9]
vars... or you could just check the regex success once and save the
trouble.

Basically, if the match fails, you don't have to check any values.

Most Perl code from gurus checks the match success immediately.

Most Ruby idioms do the same.

> I certainly respect Randal's abilities and the suggestion that it's
> smart to test regex success or failure in _Perl_ is very wise, that's
> because Perl's regex implementation is busted with regard to setting
> $1..$n to undef on failed regex.  That "feature" is by now a well
> known bug and it forces Perl programmers to "work around it" by
> testing regex success rather than simply encourage programmers to test
> for valid inputs and produce valid outputs.

Um. I never heard of that "bug", and there are at least as many
arguments _for_ as _against_ it.  Just as with the exclusion of the '.'
and '..' entries in directory listings in Python's os.listdir() method.
I prefer Ruby's treatment of the situation, but I wouldn't call perl's
behavior a bug, IMHO.

> I'd rather not have to test for regex success before assigning matches
> to variables if I didn't have to.  I'd rather just code my methods to
> test for valid inputs -- I have to do this anyway if I'm writing code
> that isn't going to blow up on bad inputs.  Why should I _have_ to do
> more than just due diligence unless the _language_ forces me to.

I frequently use regexes to validate input in the first place. If it
matches, it's valid input and I can begin processing it.  If not, croak.

> I'm moving to Ruby because I'm looking for something that isn't quite
> as broken as Perl but offers me a better OO implementation than [incr
> Tcl].  Not because I "can write Perl in any language!"

Again, Perl's becoming a bit schizophrenic, yes, but I wouldn't call
it broken... yet.  However, Perl 6 looks to be a clarification of the
future of Perl, as well as cleaning up some of the dirtier corners.

As far as "write Perl in any language", weren't you the one asking how
to accomplish a Perl idiom in Ruby? (see OP)  Several people gave you a
typical Ruby solution and you kept complaining how unlike Perl it was.

Thus said Dossy:
   "Maybe this is Perl envy, ..."
   "More Perl wantsarray() envy, too."
And here you are defending Perl's behavior:
   "As I said, this is more Perl wantarray() envy.  In perl, the =~
    operator knows if it's being used in the context of expecting a
    scalar vs. an array."

How can you so adamantly prefer Ruby over a "broken", "busted",
"bug"-ridden Perl while constantly wanting Ruby to be more like Perl?
Idioms, by definition, vary.  If Perl's context-sensitive nature is this
important, maybe you should stick with it.

Tim Hammerquist
-- 
Anyway, comdemning her to an eternity in Hell, just because
she turned you down... That's a really shitty thing to do.
    -- Death, The Sandman