git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Andrew Sayers <andrew-git@pileofstuff.org>
To: Subho Sankar Banerjee <subs.zero@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH][GIT.PM 2/3] Getting rid of throwing Error::Simple objects in favour of simple Perl scalars which can be caught in eval{} blocks
Date: Sat, 19 May 2012 10:38:41 +0100	[thread overview]
Message-ID: <4FB76A21.7000801@pileofstuff.org> (raw)
In-Reply-To: <1337411317-14931-2-git-send-email-subs.zero@gmail.com>

I'll limit myself to a style review here - other people can say better
than me about the deeper issues.

On 19/05/12 08:08, Subho Sankar Banerjee wrote:
<snip>
> @@ -160,7 +160,7 @@ sub repository {
>  	if (defined $args[0]) {
>  		if ($#args % 2 != 1) {
>  			# Not a hash.
> -			$#args == 0 or throw Error::Simple("bad usage");
> +			$#args == 0 or die "bad usage";

This is valid and no worse than before, but I find this use of the "or"
operator slightly confusing.  I find it easier to read either:

	<verb> or <fail>
	OR:
	<fail> unless <noun>

For example:

	do_something($foo) or die "couldn't do_something with '$foo'";
	OR:
	die "'$foo' is not a something" unless is_something($foo);

<snip>
> @@ -1041,7 +1041,7 @@ sub _temp_cache {
>  
>  		($$temp_fd, $fname) = File::Temp->tempfile(
>  			'Git_XXXXXX', UNLINK => 1, DIR => $tmpdir,
> -			) or throw Error::Simple("couldn't open new temp file");
> +			) or die "couldn't open new temp file";

This is a good example of where I think "or" is appropriate.

Think of it in terms of an English sentence.  Which of these would you
find easier to read:

	It is raining or go out and play
	OR:
	Go out and play unless it is raining

	Find your umbrella or cancel the trip
	OR:
	Cancel the trip unless find your umbrella


A bit of background for people who aren't (primarily) Perl programmers:

As an expressive language that promotes "more than one way to do it",
Perl has a long tradition of supporting many redundant ways of spelling
"if (...) { ... }".  Common examples include:

	if ( $x ) { do_something() }
	do_something() if $x;

	unless ( $x ) { do_something() }
	do_something() unless $x;

	$x && do_something();
	$x || do_something();

	$x and do_something();
	$x or do_something();

Sometimes people find very practical reasons why these aren't good
programming practice, but the rest of the time everyone just argues
about whether they're good grammar.

The "&&" and "||" operators are an example of bad programming practice -
these operators have relatively high precedence, so tend to behave
unintuitively when used in (often regrettably) complex ways.  The "and"
and "or" operators behave just like "&&" and "||", but with a precedence
low enough to avoid weirdness.  See [1] for an example.

Some people consider anything but a traditional prefix-if() statement to
be bad grammar (I believe "Perl Best Practices" makes the argument,
which is definitive for many people).  Other people say anything in the
language is by definition fair game.  The rest of us spend a lot of time
making arguments like the above, and frankly I think we gain more from
the debate than the conclusion.

	- Andrew

[1] http://perldoc.perl.org/perlop.html#C-style-Logical-Defined-Or

  reply	other threads:[~2012-05-19  9:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-26  4:15 Git.pm Subho Banerjee
2012-04-26 18:41 ` Git.pm Randal L. Schwartz
2012-04-26 18:58 ` Git.pm Tim Henigan
2012-04-26 20:10   ` Git.pm Subho Banerjee
2012-04-26 20:31     ` Git.pm Jonathan Nieder
2012-05-10 13:19       ` Git.pm Subho Banerjee
2012-05-10 15:16         ` Git.pm Jonathan Nieder
2012-05-10 15:54         ` Git.pm demerphq
2012-05-10 16:18           ` Git.pm Subho Banerjee
2012-05-10 17:22             ` Git.pm demerphq
2012-05-10 16:20           ` Git.pm Junio C Hamano
2012-05-10 17:38             ` Git.pm demerphq
2012-05-10 20:55         ` Git.pm Andrew Sayers
2012-05-11  8:27           ` Git.pm demerphq
2012-05-11 16:56         ` Git.pm Randal L. Schwartz
2012-05-11 18:10           ` Git.pm Junio C Hamano
2012-05-19  7:08             ` [PATCH][GIT.PM 1/3] Ignore files produced from exuberant-ctags Subho Sankar Banerjee
2012-05-19  7:08               ` [PATCH][GIT.PM 2/3] Getting rid of throwing Error::Simple objects in favour of simple Perl scalars which can be caught in eval{} blocks Subho Sankar Banerjee
2012-05-19  9:38                 ` Andrew Sayers [this message]
2012-05-23 11:02                   ` Subho Banerjee
2012-05-23 19:36                     ` Andrew Sayers
2012-05-19  7:08               ` [PATCH][GIT.PM 3/3] Perl code uses eval{}/die instead of Error::Simple and Git::Error::Command Subho Sankar Banerjee
2012-04-26 19:17 ` Git.pm Junio C Hamano
2012-04-26 19:59 ` Git.pm Sam Vilain

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FB76A21.7000801@pileofstuff.org \
    --to=andrew-git@pileofstuff.org \
    --cc=git@vger.kernel.org \
    --cc=subs.zero@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).