Please feel free to point out obvious things
that I’m not seeing here.
I was looking at a piece of code like this:
sub1 = ""
if str =~ regex
sub1 = $1
end
and I thought three things:
I’ve never liked the $1 – I usually avoid
Perlish variables, even the common ones.
I don’t like the if.
I don’t like having to assign sub1 twice.
So I tried writing:
sub1 = regex.match(str)[1] || “”
In theory this should be the same as the other
four lines of code.
But it doesn’t work because if the match
fails, #match returns nil and I can’t call
[] on nil.
So I thought: Why don’t I make a special
MatchData object that will just return nil
for any [] call?
<side_note>
Did you know that MatchData doesn’t have a
’new’ method?? I had to do a silly hack to
create a MatchData object before adding a
singleton method to it.
</side_note>
Here’s my code:
class Regexp
alias :oldmatch :match
def match(str)
result = self.oldmatch(str)
if not result
null = /x/.match("x") # No new
def null.[](index); nil; end
result = null
end
result
end
Please feel free to point out obvious things
that I’m not seeing here.
I was looking at a piece of code like this:
sub1 = “”
if str =~ regex
sub1 = $1
end
Hee hee.
and I thought three things:
I’ve never liked the $1 – I usually avoid
Perlish variables, even the common ones.
I don’t like the if.
I don’t like having to assign sub1 twice.
So I tried writing:
sub1 = regex.match(str)[1] || “”
a = /x/.match(“abc”) && $~[1] || “” # a => “”
b = /(b)/.match(“abc”) && $~[1] || “” # b => “b”
c = /b/.match(“abc”) && $~[1] || “” # c => “”
I think that #2 in your list above is a sign of Perl envy where Perl has
no notion of nil vs empty string (which I brought up on this list a
while back) to which Timmy Hammerquist said “even Larry Wall says you
should test the success or failure of a regex!”
Having to pre-initialize the variable with an empty string does seem
kinda lame, but it’s The Ruby Way, isn’t it?
–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)
Please feel free to point out obvious things
that I’m not seeing here.
I was looking at a piece of code like this:
sub1 = “”
if str =~ regex
sub1 = $1
end
and I thought three things:
I’ve never liked the $1 – I usually avoid
Perlish variables, even the common ones.
I don’t like the if.
I don’t like having to assign sub1 twice.
So I tried writing:
sub1 = regex.match(str)[1] || “”
In theory this should be the same as the other
four lines of code.
But it doesn’t work because if the match
fails, #match returns nil and I can’t call
on nil.
(code with special MatchData object skipped)
Hal,
have you thought of introducing a new or enhancing the current
Regex#match method with two additional optional parameters (the
index and a default value)? Usage like
At Fri, 20 Sep 2002 17:01:09 +0900, Pit Capitain wrote:
have you thought of introducing a new or enhancing the current
Regex#match method with two additional optional parameters (the
index and a default value)? Usage like
I think that #2 in your list above is a sign of Perl envy where Perl has
no notion of nil vs empty string (which I brought up on this list a
Na, it’s lisp-envy. Nil and false should be indistinguishable from an empty
list.
To extend on this & the related auto-vivification issues: seems to me that
functionality of this kind is one of the few things you lose in OO, when
all types – including user defined ones – stand on equal footing.
If would be nice if nil was indistinguishable from an empty container, but
the general case would lead to madness, I suspect.
Auto-vivification of nil to a non-empty container via a signature-method
(to_ary, etc) would be quite doable, but symmetry would also require that
empty containers would automagically become nil’s as well.
(Auto-nullification?)
I don’t see it happening, since it is a huge change in the overall look and
feel of the language, and would propably lead to chaos. I would love to
be proved wrong, though!
I think that #2 in your list above is a sign of Perl envy where Perl has
no notion of nil vs empty string (which I brought up on this list a
Na, it’s lisp-envy. Nil and false should be indistinguishable from an empty
list.
To extend on this & the related auto-vivification issues: seems to me that
functionality of this kind is one of the few things you lose in OO, when
all types – including user defined ones – stand on equal footing.
That’s a wonderful thing about Ruby. Arguably, Perl is slightly better
than Ruby for string processing, and Lisp edges out Ruby for list
processing. But Ruby is much better than Perl for working with lists or
any complex data structures, and Ruby is easier to use than Lisp for
string processing.
Which isn’t to say I don’t miss some things from lisp, like macros.
I would love to