Re: using a library

Discussion in 'Perl Misc' started by Peter J. Holzer, Mar 1, 2014.

  1. On 2014-03-01 02:50, Marek Novotny <> wrote:
    > On Sat, 01 Mar 2014 01:10:10 +0000, Ben Morrow wrote:
    >> Quoth Marek Novotny <>:
    >>> print "\n";
    >>> print "You entered: $input\n";
    >>> print "The average of your numbers is: $average\n";
    >>> print "The total of all your numbers combined is: $total\n";
    >>> print "Each of your numbers divided by 2 are: $div\n\n";
    >>> print "Have a nice day!!\n\n";

    >>
    >> A great long sequence of print statements is, I'm afraid, one of the
    >> classic signs of a Perl beginner :).


    So after 19 years of Perl programming I'm still a beginner. Or rather.
    I'm a beginner again.

    >> Perl has a quoting construction
    >> called a 'here document' that is rather clearer; this was inherited from
    >> Bourne shell, so if you've learned that you might be familiar with it
    >> already:
    >>
    >> print <<OUTPUT;
    >>
    >> You entered: $input The average of your numbers is: $average The
    >> total of all your numbers combined is: $total Your numbers each
    >> divided by 2 are: $div
    >>
    >> Have a nice day!
    >>
    >> OUTPUT

    >
    > This is awesome. I just wrote a sample script to test it out. That's
    > cool! They made zero mention of this by the way.
    >
    >> (Note that I've indented the code in this post for clarity. In a real
    >> program, the final OUTPUT marker must appear at the left margin,
    >> regardless of the indentation of the surrounding code.)


    And not only the final OUTPUT marker must appear at the left margin, but
    the contents start at the left margin, too. So you either have to write
    code like this:

    if ($foo) {
    for (@bar) {
    if ($_ <= 0) {
    print <<OUTPUT;
    Oh, no! The current element of bar is $_,
    but foo is $foo.
    OUTPUT
    } elsif ($_ == 1) {
    print <<OUTPUT;
    Much better. The current element of bar is $_,
    and foo is $foo.
    OUTPUT
    } else {
    print <<OUTPUT;
    Great. The current element of bar is $_,
    and foo is still $foo.
    OUTPUT
    }
    }
    }

    which I consider totally unreadable. Or you end up postprocessing your
    strings at runtime, or shunting each into a function of its own or using
    some other workaround.


    > Believe it or not, I read it that same way, wrote a nice script that did
    > everything they asked for in one shot, and they rejected it. They wanted
    > it split up.


    Your instructors are trying very hard to act like real customers. ;-)


    >> I may get some argument from the other regulars here, but except in
    >> special circumstances I don't like using shift to pull arguments off @_.
    >> IMHO it's much clearer to put all the arguments you want in named
    >> variables with one list assignment, like this:
    >>
    >> my ($input) = @_;


    I agree.

    my ($foo, $bar, @baz) = @_;

    is cleaner than

    my $foo = shift @_;
    my $bar = shift @_;
    my @baz = @_;

    Maybe just because the former looks more like the parameter list in
    other programming languages.

    hp


    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
    Peter J. Holzer, Mar 1, 2014
    #1
    1. Advertising

  2. "Peter J. Holzer" <> writes:

    [...]


    > And not only the final OUTPUT marker must appear at the left margin, but
    > the contents start at the left margin, too. So you either have to write
    > code like this:
    >
    > if ($foo) {
    > for (@bar) {
    > if ($_ <= 0) {
    > print <<OUTPUT;
    > Oh, no! The current element of bar is $_,
    > but foo is $foo.
    > OUTPUT
    > } elsif ($_ == 1) {
    > print <<OUTPUT;
    > Much better. The current element of bar is $_,
    > and foo is $foo.
    > OUTPUT
    > } else {
    > print <<OUTPUT;
    > Great. The current element of bar is $_,
    > and foo is still $foo.
    > OUTPUT
    > }
    > }
    > }
    >
    > which I consider totally unreadable.


    It isn't much better with integrated strings:

    if ($foo) {
    for (@bar) {
    if ($_ <= 0) {
    print("Oh, no! The current element of bar is $_, but foo is $foo.\n");
    } elsif ($_ == 1) {
    print("Much better. The current element of bar is $_, and foo is $foo.\n");
    } else {
    print("Great. The current element of bar is $_, and foo is still $foo.\n");
    }
    }
    }

    ie, why does it say 'print' all the time even if it prints only one
    message per iteration and why are the conditions chained in this way despite
    there's no code after them?

    if ($foo) {
    for (@bar) {
    if ($_ <= 0) {
    $msg = "Oh, no! The current element of bar is $_, but foo is $foo.";
    } elsif ($_ == 1) {
    $msg = "Much better. The current element of bar is $_, and foo is $foo.";
    } else {
    $msg = "Great. The current element of bar is $_, and foo is still $foo.";
    }

    print($msg, "\n");
    }
    }

    One could also ask oneself why this is comparing something to 1 three
    times in a row ...

    if ($foo) {
    for (@bar) {
    given ($_ <=> 1) {
    when (-1) {
    $msg = "Oh, no! The current element of bar is $_, but foo is $foo.";
    }

    when (0) {
    $msg = "Much better. The current element of bar is $_, and foo is $foo.";
    }

    when (1) {
    $msg = "Great. The current element of bar is $_, and foo is still $foo.";
    }
    }

    print($msg, "\n");
    }
    }

    .... and why is there so much code, anyway?

    my @msgs = ('Oh, no! The current element of bar is %s, but foo is %s.',
    'Much better. The current element of bar is %s, and foo is %s.',
    'Great. The current element of bar is %s, and foo is still %s.');

    printf($msgs[($_ <=> 1) + 1]."\n", $_, $foo) for $foo ? @bar : ();

    (this is not an entirely serious suggestion, more of a suggestion that
    one should consider alternate approaches before rejecting them).
    Rainer Weikusat, Mar 1, 2014
    #2
    1. Advertising

  3. Rainer Weikusat <> writes:

    [...]

    > One could also ask oneself why this is comparing something to 1 three
    > times in a row ...


    .... which it actually doesn't because Perl numbers are usually not
    integers, ie, the original code would print the last message for real
    numbers from [0, 1] ...
    Rainer Weikusat, Mar 1, 2014
    #3
  4. Here documents (was: using a library)

    On 2014-03-01 14:16, Rainer Weikusat <> wrote:
    > "Peter J. Holzer" <> writes:
    >> And not only the final OUTPUT marker must appear at the left margin, but
    >> the contents start at the left margin, too. So you either have to write
    >> code like this:
    >>
    >> if ($foo) {
    >> for (@bar) {
    >> if ($_ <= 0) {
    >> print <<OUTPUT;
    >> Oh, no! The current element of bar is $_,
    >> but foo is $foo.
    >> OUTPUT
    >> } elsif ($_ == 1) {
    >> print <<OUTPUT;
    >> Much better. The current element of bar is $_,
    >> and foo is $foo.
    >> OUTPUT
    >> } else {
    >> print <<OUTPUT;
    >> Great. The current element of bar is $_,
    >> and foo is still $foo.
    >> OUTPUT
    >> }
    >> }
    >> }
    >>
    >> which I consider totally unreadable.

    >
    > It isn't much better with integrated strings:
    >
    > if ($foo) {
    > for (@bar) {
    > if ($_ <= 0) {
    > print("Oh, no! The current element of bar is $_, but foo is $foo.\n");
    > } elsif ($_ == 1) {
    > print("Much better. The current element of bar is $_, and foo is $foo.\n");
    > } else {
    > print("Great. The current element of bar is $_, and foo is still $foo.\n");
    > }
    > }
    > }


    This isn't the same. Equivalent with single double quoted strings would be:

    if ($foo) {
    for (@bar) {
    if ($_ <= 0) {
    print("Oh, no! The current element of bar is $_,\nbut foo is $foo.\n");
    } elsif ($_ == 1) {
    print("Much better. The current element of bar is $_,\nand foo is $foo.\n");
    } else {
    print("Great. The current element of bar is $_,\nand foo is still $foo.\n");
    }
    }
    }

    which I agree is only slightly better. But Ben was contrasting this
    with multiple print statements, so that would be:

    if ($foo) {
    for (@bar) {
    if ($_ <= 0) {
    print "Oh, no! The current element of bar is $_,\n";
    print "but foo is $foo.\n";
    } elsif ($_ == 1) {
    print "Much better. The current element of bar is $_,\n";
    print "and foo is $foo.\n";
    } else {
    print "Great. The current element of bar is $_,\n";
    print "and foo is still $foo.\n";
    }
    }
    }

    which I do consider significantly more readable than with here
    documents. In a case like this I might just use print with multiple
    arguments:

    if ($foo) {
    for (@bar) {
    if ($_ <= 0) {
    print "Oh, no! The current element of bar is $_,\n",
    "but foo is $foo.\n";
    } elsif ($_ == 1) {
    print "Much better. The current element of bar is $_,\n",
    "and foo is $foo.\n";
    } else {
    print "Great. The current element of bar is $_,\n",
    "and foo is still $foo.\n";
    }
    }
    }

    Although one print per line has the advantage that I can use say
    instead of print and remove the \n, so I think I would prefer

    if ($foo) {
    for (@bar) {
    if ($_ <= 0) {
    say "Oh, no! The current element of bar is $_,";
    say "but foo is $foo.";
    } elsif ($_ == 1) {
    say "Much better. The current element of bar is $_,";
    say "and foo is $foo.";
    } else {
    say "Great. The current element of bar is $_,";
    say "and foo is still $foo.";
    }
    }
    }

    > ie, why does it say 'print' all the time even if it prints only one
    > message per iteration and why are the conditions chained in this way despite
    > there's no code after them?

    [...]
    > ... and why is there so much code, anyway?


    Completely irrelevant question. The loop and the conditions are just
    there to get some reasonable indentation and a bit of code between the
    here documents for the here documents to obscure. The aren't meant to
    do anything useful (and the here document's aren't supposed to be Nobel
    price material, either).


    > my @msgs = ('Oh, no! The current element of bar is %s, but foo is %s.',
    > 'Much better. The current element of bar is %s, and foo is %s.',
    > 'Great. The current element of bar is %s, and foo is still %s.');
    >
    > printf($msgs[($_ <=> 1) + 1]."\n", $_, $foo) for $foo ? @bar : ();
    >
    > (this is not an entirely serious suggestion, more of a suggestion that
    > one should consider alternate approaches before rejecting them).


    This is probably more relevant to the topic, since separating the literal
    strings from the logic makes the pain of non-indented here documents
    somewhat more bearable. But this:

    my @msgs = (<<S0,
    Oh, no! The current element of bar is %s,
    but foo is %s.
    S0
    <<S1,
    Much better. The current element of bar is %s,
    and foo is %s.
    S1
    <<S2,
    Great. The current element of bar is %s,
    and foo is still %s.
    S2
    );

    is still uglier than using normal strings, and I'm not even talking
    about monstrosities such as this:

    my @msgs = (<<S0, <<S1, <<S2);
    Oh, no! The current element of bar is %s,
    but foo is %s.
    S0
    Much better. The current element of bar is %s,
    and foo is %s.
    S1
    Great. The current element of bar is %s,
    and foo is still %s.
    S2

    hp


    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
    Peter J. Holzer, Mar 1, 2014
    #4
  5. Peter J. Holzer

    Tim McDaniel Guest

    Re: Here documents (was: using a library)

    In article <>,
    Peter J. Holzer <> wrote:
    >separating the literal strings from the logic makes the pain of
    >non-indented here documents somewhat more bearable.


    Helps the whole separation of logic from presentation, which many of
    my ork-places have struggled with. It also makes it more
    internationalizable, if that's ever a concern of yours.

    >I'm not even talking about monstrosities such as this:
    >
    >my @msgs = (<<S0, <<S1, <<S2);
    >Oh, no! The current element of bar is %s,
    >but foo is %s.
    >S0
    >Much better. The current element of bar is %s,
    >and foo is %s.
    >S1
    >Great. The current element of bar is %s,
    >and foo is still %s.
    >S2


    .... you can actually DO that?! That is so COOL! I HAVE to do that!
    Thanks so much!

    --
    Tim McDaniel,
    Tim McDaniel, Mar 1, 2014
    #5
  6. Re: Here documents (was: using a library)

    On 2014-03-01 23:51, Tim McDaniel <> wrote:
    > In article <>,
    > Peter J. Holzer <> wrote:
    >>I'm not even talking about monstrosities such as this:
    >>
    >>my @msgs = (<<S0, <<S1, <<S2);
    >>Oh, no! The current element of bar is %s,
    >>but foo is %s.
    >>S0
    >>Much better. The current element of bar is %s,
    >>and foo is %s.
    >>S1
    >>Great. The current element of bar is %s,
    >>and foo is still %s.
    >>S2

    >
    > ... you can actually DO that?! That is so COOL! I HAVE to do that!
    > Thanks so much!
    >


    What have I done!?

    hp


    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
    Peter J. Holzer, Mar 2, 2014
    #6
  7. Re: Here documents

    "Peter J. Holzer" <> writes:

    [...]

    > I'm not even talking about monstrosities such as this:
    >
    > my @msgs = (<<S0, <<S1, <<S2);
    > Oh, no! The current element of bar is %s,
    > but foo is %s.
    > S0
    > Much better. The current element of bar is %s,
    > and foo is %s.
    > S1
    > Great. The current element of bar is %s,
    > and foo is still %s.
    > S2


    I don't think this is so bad, either. Maintaining an array of multi-line
    strings ought to be easier with 'syntactical elements of Perl' out of
    the way, including that there's no need to quote anything in this case.
    Rainer Weikusat, Mar 2, 2014
    #7
  8. Peter J. Holzer

    Tim McDaniel Guest

    Re: Here documents (was: using a library)

    In article <>,
    Peter J. Holzer <> wrote:
    >On 2014-03-01 23:51, Tim McDaniel <> wrote:
    >> In article <>,
    >> Peter J. Holzer <> wrote:
    >>>I'm not even talking about monstrosities such as this:
    >>>
    >>>my @msgs = (<<S0, <<S1, <<S2);
    >>>Oh, no! The current element of bar is %s,
    >>>but foo is %s.
    >>>S0
    >>>Much better. The current element of bar is %s,
    >>>and foo is %s.
    >>>S1
    >>>Great. The current element of bar is %s,
    >>>and foo is still %s.
    >>>S2

    >>
    >> ... you can actually DO that?! That is so COOL! I HAVE to do that!
    >> Thanks so much!

    >
    >What have I done!?


    I believe that expressing that in all earnestness is the membership
    criterion for the Frankenstein Society.

    Leaving the Society is often done by shouting at the hero,
    "No, this cannot be! I AM INVINCIBLE!!!"

    --
    Tim McDaniel,
    Tim McDaniel, Mar 2, 2014
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mythran
    Replies:
    0
    Views:
    2,403
    Mythran
    Aug 24, 2004
  2. Alan Ferrandiz [MCT]
    Replies:
    0
    Views:
    435
    Alan Ferrandiz [MCT]
    Sep 11, 2004
  3. Sweep

    Library in library...

    Sweep, Dec 8, 2003, in forum: C++
    Replies:
    1
    Views:
    377
    Jack Klein
    Dec 9, 2003
  4. Replies:
    6
    Views:
    817
    red floyd
    May 10, 2005
  5. David Soukal

    library using library?

    David Soukal, May 14, 2004, in forum: C Programming
    Replies:
    10
    Views:
    609
    Brian Gough
    May 17, 2004
Loading...

Share This Page