git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Subho Banerjee <subs.zero@gmail.com>
Date
May 23, 2012, 11:02 UTC
Message-ID
<CAB3zAY3nVDiBH6kJKK9YTXKsaFZZnUz7AAFh5z+J0VhXHjYiMQ@mail.gmail.com>
In-Reply-To
<4FB76A21.7000801@pileofstuff.org>

Hi, The semantic

>        <fail> unless <noun>
works well when the <fail> part of the code is a singular statement.
But it is of ungainly when there are a couple of statements to be
executed as a block. In this case, I believe that a the conjunctive
,,or''/,,and'' statement makes more sense. In the sense -
                 <verb1> or <die_gracefully1> and <die_gracefully2>
I believe this is easier to read compared to -
                 <die_gracefully1> and <die_gracefully2> unless <noun>
especially if you have a larger block of commands to execute in case
of the failure. I believe the easiest to read would be a classical C
styled if() block, but that would make the code more "verbose" :-)

But I am open to the change of the ,,or''s to ,,unless"s. They are just cosmetic changes. I can submit patches to that effect if that's what you guys want.

Cheers, Subho.

On Sat, May 19, 2012 at 3:08 PM, Andrew Sayers <andrew-git@pileofstuff.org> wrote:

Show 85 quoted lines
> 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
Previous: Andrew SayersNext: Andrew Sayers
Message 20 of 24 in “Git.pm”
  1. Subho BanerjeeApr 26, 2012
  2. Randal L. SchwartzApr 26, 2012
  3. Tim HeniganApr 26, 2012
  4. Subho BanerjeeApr 26, 2012
  5. Jonathan NiederApr 26, 2012
  6. Subho BanerjeeMay 10, 2012
  7. Jonathan NiederMay 10, 2012
  8. demerphqMay 10, 2012
  9. Subho BanerjeeMay 10, 2012
  10. demerphqMay 10, 2012
  11. Junio C HamanoMay 10, 2012
  12. demerphqMay 10, 2012
  13. Andrew SayersMay 10, 2012
  14. demerphqMay 11, 2012
  15. Randal L. SchwartzMay 11, 2012
  16. Junio C HamanoMay 11, 2012
  17. [GIT.PM 1/3] Ignore files produced from exuberant-ctagsSubho Sankar Banerjee, May 19, 2012
  18. [GIT.PM 2/3] Getting rid of throwing Error::Simple objects in favour of simple Perl scalars which can be caught in eval{} blocksSubho Sankar Banerjee, May 19, 2012
  19. Andrew SayersMay 19, 2012
  20. Subho BanerjeeMay 23, 2012
  21. Andrew SayersMay 23, 2012
  22. [GIT.PM 3/3] Perl code uses eval{}/die instead of Error::Simple and Git::Error::CommandSubho Sankar Banerjee, May 19, 2012
  23. Junio C HamanoApr 26, 2012
  24. Sam VilainApr 26, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.