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:
demerphq
Date:
May 28, 2010 23:48
Subject:
Re: [perl #75350] PATCH: revamp ibcmp_utf8() for efficiency, clarity
Message ID:
AANLkTilbFov-slulpxDvIhN_27LyOjpfPB9JLQMhKsas@mail.gmail.com
On 29 May 2010 01:28, karl williamson <public@khwilliamson.com> wrote:
> 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.

Me too. If you think this function should be renamed, and we can still
proved a back-compat alias should something actually be using it, then
go ahead and rename it.

Be bold!

>>
>> 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?

Not wanting to reopen the tab-verus-spaces debate, i have the
impression that most people find it easier to work with spaces as tabs
can have variable widths and dont mix nicely with spaces.

> 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.

Personally I prefer my elses to feel warm and loved...

> 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.

Me too.

> 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,

Actually there are.

First do this:

git config --global color.ui auto

That should turn on colored output for git. Once the colored diff is
enabled you will easily spot trailing whitespace because it will be
highlighted in red when you do git diff.

Additionally git supports hooks for various actions and events, and I
think one of the hooks (default disabled but distributed with git
iirc) does whitespace cleanup on commit.

Also, now that we use git the old objection to trimming and
normalizing whitespace doesn't hold anymore, as we have

git blame -w

to help us see past the whitespace fixups.

> as my vim editor seems to always be putting them in, unbeknownst to me.

Vim does this to me too. It seems to be a byproduct of the arcane
confused modal editing system.

I hate vim. Yet I use it. Sigh.

> I suppose I can put a wrapper around my local copy of 'git add' to check for this.

Nah, Look into configuring git a bit better and you wont need to do that.

OTOH I have a tool I wrote called "clean-commit" which autotrims and
expands tabs on the stuff ive modified.

cheers
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

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