From: demerphq <demerphq@gmail.com>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: "Matt Kraai" <kraai@ftbfs.org>, git@vger.kernel.org
Subject: Re: [PATCH] gitweb: merge boolean feature subroutines
Date: Sun, 4 Jan 2009 12:41:14 +0100 [thread overview]
Message-ID: <9b18b3110901040341n5ff5fa09s878228131d11d2a6@mail.gmail.com> (raw)
In-Reply-To: <7vvdsv3af6.fsf@gitster.siamese.dyndns.org>
2009/1/4 Junio C Hamano <gitster@pobox.com>:
> demerphq <demerphq@gmail.com> writes:
>
>> 2009/1/3 Matt Kraai <kraai@ftbfs.org>:
>> [...]
>>> -sub feature_blame {
>>> - my ($val) = git_get_project_config('blame', '--bool');
>>> +sub feature_bool {
>>> + my $key = shift;
>>> + my ($val) = git_get_project_config($key, '--bool');
>>>
>>> if ($val eq 'true') {
>>> return 1;
>>
>> Maybe that should be:
>>
>> return ($val eq 'true');
>>
>> as It is not a good idea to use 0 as a replacement for perls false, as
>> the two have different behaviour.
>
> I'd rather want to keep our scripts free of deep Perl magic. Even if
> there are SVs that are interpreted as false other than 0, that does not
> necessarily mean you have to fear that 0 can sometimes evaluate to true.
No, thats not the point. The point is that why should the code do more
work to return a value that a perl programmer might find unexpected.
Especially when the function has the word "bool" in it. Its like
writing a function whose name says "int" that returns a double. If the
routine was not called "bool" then it wouldnt matter at all.
> As long as you refrain from doing something crazy like "0 but true",
> people who are not (and/or are not inclined to become) familiar with the
> gory innards of Perl can rely on 0 being false and 1 being true when
> calling feature_something subs, no?
Why execute more opcodes, and return a slightly surprising false, when
you dont have to?
Is it really deep perl magic to do:
return $val eq 'true';
instead of
return $val eq 'true' ? 1 : 0;
or the actual use:
if ($val eq 'true') {
return 1
} else {
return 0
}
Isn't the former superior just on pure minimalism metrics? Theres less
code to understand, less code to go wrong, and as a bonus it returns a
true boolean. Isn't that just a win-win-win? I mean most perl
programmers I know would instantly convert the latter two to the first
just on the grounds that the first version is the clearest expression
of the desired intent.
Anyway, leave it or not, its a minor nit.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
next prev parent reply other threads:[~2009-01-04 11:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-03 15:31 [PATCH] gitweb: merge boolean feature subroutines Matt Kraai
2009-01-03 15:31 ` [PATCH] gitweb: pass the key to the " Matt Kraai
2009-01-03 16:18 ` [PATCH] gitweb: merge boolean " demerphq
2009-01-03 16:40 ` Matt Kraai
2009-01-03 16:51 ` demerphq
2009-01-03 17:13 ` Matt Kraai
2009-01-03 17:41 ` demerphq
2009-01-04 5:30 ` Junio C Hamano
2009-01-04 11:41 ` demerphq [this message]
2009-01-04 15:58 ` Matt Kraai
2009-01-04 22:07 ` Jakub Narebski
2009-01-04 21:25 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b18b3110901040341n5ff5fa09s878228131d11d2a6@mail.gmail.com \
--to=demerphq@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kraai@ftbfs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).