develooper Front page | perl.perl5.porters | Postings from May 2010

Re: [perl #75350] PATCH: revamp ibcmp_utf8() for efficiency, clarity

Thread Previous | Thread Next
From:
karl williamson
Date:
May 28, 2010 16:29
Subject:
Re: [perl #75350] PATCH: revamp ibcmp_utf8() for efficiency, clarity
Message ID:
4C0051B3.2050208@khwilliamson.com
demerphq wrote:
> On 25 May 2010 20:24, karl williamson <perlbug-followup@perl.org> wrote:
>> # New Ticket Created by  karl williamson
>> # Please include the string:  [perl #75350]
>> # in the subject line of all future correspondence about this issue.
>> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=75350 >
>>
>>
>> The first times I looked at this routine, it seemed incomprehensible.  I
>> had to come back to it to fix a bug after working on other parts of Perl
>> for a while, and it wasn't as foreign as before.  But I had to really
>> understand it, so I started adding comments, and discovered that it was
>> checking a number of things each time in the loop that could have  been
>> figured out once.  So I ended up revamping it, keeping the same algorithm.
> 
> Somebody please figure out how to clone Karl so we have a backup. Thanks.
> 
> On a more serious note...
> 
> This looks much nicer to read than the original. ++ to you.
> 
> +Returns true if the strings s1 and s2 differ case-insensitively, false
> +if they are equal case-insensitively.  Note that this is the complement of what
> +you might expect (perhaps it would have been better to name it C<ibncmp_utf8>).
> 
> Seems to me that cmp routines always behave like this, they return -1
> for inorder but different, 0 for different, and 1 for reverse order.

I agree that I was wrong, and ibncmp is not a good name, but this 
routine returns only TRUE or FALSE, unlike the cmp routines.  A better 
comparison would be with functions like memNE.  I'm always startled when 
I read code calling this function, because it looks like it's doing the 
wrong thing to me, and I'm a firm believer that names can help or hinder.
> 
> Anyway, the only other thing that occurs to me is that if it is going
> to be rewritten, and reindented, could we lose the tabs please?

Is this an unwritten rule that new code shouldn't have tabs?  I'm happy 
to go along with that.  After all, I have learned to mostly do uncuddled 
else's, which is a written rule, though I don't understand why it is 
that way, and sometimes I forget.  The best I can think of is that it is 
from some sort of dyslexia that I and K&R don't happen to have (I'm told 
that's why serifs on fonts were developed);  I've read Damian's 
explanation for "Perl Best Practices", and found it totally 
unconvincing.  Anyway, no need to try to convert me; I'm conforming to 
uncuddled elses.  And I agree it's better to expand tabs, my editor can 
handle that well; I just didn't know.

And while we're on the subject.  Apparently another unwritten rule is 
about trailing white space.  It would be best if that were written down, 
and there was some sort of checker for that, as my vim editor seems to 
always be putting them in, unbeknownst to me.  I suppose I can put a 
wrapper around my local copy of 'git add' to check for this.

> 
> Besides these nits I vote apply.
> 
> Yves
> 
> 
> 
> 


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About