Re: Help with an operator precedence (?) puzzle

Discussion in 'Perl Misc' started by Tim McDaniel, May 12, 2014.

  1. Tim McDaniel

    Tim McDaniel Guest

    In article <>,
    Henry Law <> wrote:
    >#!/usr/bin/perl
    >use strict;
    >use warnings;
    >use 5.010;
    >
    >sub tryit {
    > my ( $user, $conf, $parms ) = @_;
    > $@ = "reset_user: invalid parameters\n" and return if $parms==1;
    > $@ = "reset_user: '$user' doesn't exist\n" and return if $parms==2;
    >}


    I think you should stop dicking with the builtin $@ variable. "man
    perlvar" says what happens when a few builtin variables are assigned
    to, but $@ isn't one of them, so I see no guarantee that it will work.

    >If I compile it Perl warns me: "Found = in conditional, should be == at
    >tryout.pl line 8."


    Well, yeah. "and" takes two operands, and the first operand is
    evaluaed in a boolean context (a conditional), and
    $@ = "reset_user: invalid parameters\n"
    indeed has = in a conditional, as stated. A pirated Programming
    Perl says "the final value of the variable on the left is returned as
    the value of the assignment as a whole", so the LHS is always true, so
    it works, for some value of "works".

    $@ = 3+4 and return if $parms==1;
    produces the same warning.

    >But line 9 is virtually identical, except for the presence of an
    >interpolated variable, and it compiles clean! Blowed if I know why.


    At a guess, the "Found = in conditional" warning is a heuristic that
    gets confused somehow by an interpolated string in particular. That
    is, it's the lack of a message line 9 that is the problematic one, not
    line 8.

    >Aside from explaining what I've misunderstood, what's the most Perlish
    >way to set a variable and return, all in one statement?


    Is there a problem with the comma operator?
    $frog = "green", return if blort();

    But personally I don't like flow of control in an expression, so I'd
    just write
    if (blort()) {
    $frog = "green";
    return;
    }

    --
    Tim McDaniel,
     
    Tim McDaniel, May 12, 2014
    #1
    1. Advertising

  2. Tim McDaniel

    Uri Guttman Guest

    >>>>> "HL" == Henry Law <> writes:

    HL> On 12/05/14 23:46, Tim McDaniel wrote:
    >> I think you should stop dicking with the builtin $@ variable.


    HL> Umm; I thought that $@ was specifically for returning stuff from a
    HL> subroutine that had used its "proper" return value for
    HL> success/failure. I know that lots of CPAN modules use it in that
    HL> way.

    from perldoc perlvar:

    $@ The Perl syntax error message from the last "eval()" operator.
    If $@ is the null string, the last "eval()" parsed and executed
    correctly (although the operations you invoked may have failed
    in the normal fashion).

    so where does it say you should assign into $@? i bet those modules you
    claim do it are just dealing with passing back other errors found from
    eval and related things. it is not how you should be passing back errors
    (and globals are a poor idea for that too).

    you can return errors directly with return if you api is designed to
    know when you have good data or for an error return undef. there are
    other variations. or you can just die which will set $@ correctly and
    let the caller trap that with eval or try/catch (from a module).

    uri
     
    Uri Guttman, May 13, 2014
    #2
    1. Advertising

  3. Tim McDaniel

    Tim McDaniel Guest

    In article <>,
    Henry Law <> wrote:
    >On 12/05/14 23:46, Tim McDaniel wrote:
    >> I think you should stop dicking with the builtin $@ variable.

    >
    >Umm; I thought that $@ was specifically for returning stuff from a
    >subroutine that had used its "proper" return value for
    >success/failure. I know that lots of CPAN modules use it in that
    >way.


    Hm! I just did "cd /usr/share/perl/5.14.2" and
    find . -type f -name '*.p[lm]' -print0 | xargs -0 grep '\$@ *=' | wc
    find . -type f -name '*.p[lm]' -print0 | xargs -0 grep '\$@' | wc

    There were 643 lines that referred to $@. But since $@ is set by
    die(), implicitly setting $@, catching die() using eval(), and
    examining the value of $@ are standard techniques for exception
    processing.

    There were 42 matching the first pattern, but most of them were like
    "$@ =~ m/.../", doing a match instead of altering it.

    But I found an assignment or s/// in
    Net/FTP.pm
    Test/More.pm
    Module/Build/Base.pm
    CGI.pm
    Pod/ParseUtils.pm
    AutoLoader.pm
    CPAN/Distribution.pm
    CPAN/Distroprefs.pm
    SelfLoader.pm
    Text/Balanced.pm
    perl5db.pl
    Locale/Maketext.pm
    Archive/Tar.pm

    Nevertheless, I still think you shouldn't *set* $@ except by using
    Try::Tiny or the like, or in serious need. I've never seen code
    setting $@, and only seen it referring to $@ when using die/eval.
    $@ is a global variable and is modified by die() and fatal errors, so
    those can be drawbacks.

    But if someone experienced like Ben has a different opinion, I'd like
    to hear it.

    --
    Tim McDaniel,
     
    Tim McDaniel, May 13, 2014
    #3
  4. Tim McDaniel

    Tim McDaniel Guest

    In article <>,
    Henry Law <> wrote:
    >On 13/05/14 04:29, Uri Guttman wrote:
    >> if you api is designed to
    >> know when you have good data or for an error return undef.

    >
    >Well, that's what I'm trying to do. But if I have a sub which has
    >multiple different ways of going wrong, how is the caller to find out
    >what the problem was?


    Off the top of my head.

    (0) Your sub can die on error. By default, that kills the program.
    You document this and say that, if the caller doesn't want to die,
    they should use Try::Tiny or something like it to catch the error.
    Then they can look at $@ for the exact reason if that's useful.

    Really, error return codes are inherently unsafe -- it takes positive
    effort to detect them and do something sensible. If you overlook a
    die, you WILL learn about it. Failsafe.

    But it's a pain if the caller usually wants to continue.

    (1) UNIX has the convention of processes exiting with 0 if all is
    well, various non-zero codes if not. This can be seen in Perl with $!
    and $@. I do not recommend numeric codes; that's just a limitation
    that processes are only given a numeric exit code. So you could do

    return 'It is Tuesday' if ...;
    # do the processing.
    return '';

    It has the slight disadvantage of being like system(): you test for
    success with !thething(...) instead of thething(...).

    (2) At my $ORKPLACE, the convention in any sort of complicated
    situation is to return an anonymous hash for separate parts.

    { THE_VALUE_WE_WANT_TO_RETURN_NORMALLY => 23, ERROR => '' }

    { THE_VALUE_WE_WANT_TO_RETURN_NORMALLY => undef, ERROR => "Tuesday!" }

    --
    Tim McDaniel,
     
    Tim McDaniel, May 13, 2014
    #4
  5. (Tim McDaniel) writes:
    > In article <>,
    > Henry Law <> wrote:


    [...]

    >>But line 9 is virtually identical, except for the presence of an
    >>interpolated variable, and it compiles clean! Blowed if I know why.

    >
    > At a guess, the "Found = in conditional" warning is a heuristic that
    > gets confused somehow by an interpolated string in particular. That
    > is, it's the lack of a message line 9 that is the problematic one, not
    > line 8.


    This warning is produced by a routine named S_scalarboolean (op.c) and
    it warns if it encounters a scalar assignment whose right operand is a
    constant (in boolean context).
     
    Rainer Weikusat, May 15, 2014
    #5
  6. On 5/12/2014 3:46 PM, Tim McDaniel wrote:
    > In article <>,
    > Henry Law <> wrote:
    >> #!/usr/bin/perl
    >> use strict;
    >> use warnings;
    >> use 5.010;
    >>
    >> sub tryit {
    >> my ( $user, $conf, $parms ) = @_;
    >> $@ = "reset_user: invalid parameters\n" and return if $parms==1;
    >> $@ = "reset_user: '$user' doesn't exist\n" and return if $parms==2;
    >> }

    >
    > I think you should stop dicking with the builtin $@ variable. "man
    > perlvar" says what happens when a few builtin variables are assigned
    > to, but $@ isn't one of them, so I see no guarantee that it will work.
    >
    >> If I compile it Perl warns me: "Found = in conditional, should be == at
    >> tryout.pl line 8."

    >
    > Well, yeah. "and" takes two operands, and the first operand is
    > evaluaed in a boolean context (a conditional), and
    > $@ = "reset_user: invalid parameters\n"
    > indeed has = in a conditional, as stated. A pirated Programming
    > Perl says "the final value of the variable on the left is returned as
    > the value of the assignment as a whole", so the LHS is always true, so
    > it works, for some value of "works".
    >
    > $@ = 3+4 and return if $parms==1;
    > produces the same warning.
    >
    >> But line 9 is virtually identical, except for the presence of an
    >> interpolated variable, and it compiles clean! Blowed if I know why.

    >
    > At a guess, the "Found = in conditional" warning is a heuristic that
    > gets confused somehow by an interpolated string in particular. That
    > is, it's the lack of a message line 9 that is the problematic one, not
    > line 8.
    >
    >> Aside from explaining what I've misunderstood, what's the most Perlish
    >> way to set a variable and return, all in one statement?

    >
    > Is there a problem with the comma operator?
    > $frog = "green", return if blort();
    >
    > But personally I don't like flow of control in an expression, so I'd
    > just write
    > if (blort()) {
    > $frog = "green";
    > return;
    > }
    >


    Alternative if comma operator "ist nicht schoen bei mir".

    do {$frog="green"} and return if blort();

    --
    Charles DeRykus
     
    Charles DeRykus, May 15, 2014
    #6
  7. Tim McDaniel

    Tim McDaniel Guest

    In article <ll38gm$eq7$>,
    Charles DeRykus <> wrote:
    >Alternative if comma operator "ist nicht schoen bei mir".
    >
    >do {$frog="green"} and return if blort();


    I would say "and" is intrinsically fragile for this. In most cases in
    Perl, where you can use a constant, you can use an expression. ("use"
    is the only counterexample I thought of off the top of my head.)

    But not here:

    do { $frog = "green" } and return if blort();

    will always work, but

    do { $frog = $toad } and return if blort();

    will fail if $toad happens to have one of the Perl false values.

    Either use comma, or make it a standard "if" block.

    --
    Tim McDaniel,
     
    Tim McDaniel, May 15, 2014
    #7
  8. On 5/15/2014 2:29 PM, Tim McDaniel wrote:
    > In article <ll38gm$eq7$>,
    > Charles DeRykus <> wrote:
    >> Alternative if comma operator "ist nicht schoen bei mir".
    >>
    >> do {$frog="green"} and return if blort();

    >
    > I would say "and" is intrinsically fragile for this. In most cases in
    > Perl, where you can use a constant, you can use an expression. ("use"
    > is the only counterexample I thought of off the top of my head.)
    >
    > But not here:
    >
    > do { $frog = "green" } and return if blort();
    >
    > will always work, but
    >
    > do { $frog = $toad } and return if blort();
    >
    > will fail if $toad happens to have one of the Perl false values.


    I think I'd backstop it in non-trivial cases: do{ ... ;1}

    >
    > Either use comma, or make it a standard "if" block.



    The comma op is ok. Not in this example, but, a d'oh moment is possible
    with a comma op too: ....,return or ....

    I think I'd use a "do" block if short; otherwise, "if".

    --
    Charles DeRykus
     
    Charles DeRykus, May 15, 2014
    #8
  9. Charles DeRykus <> writes:
    > On 5/15/2014 2:29 PM, Tim McDaniel wrote:
    >> In article <ll38gm$eq7$>,
    >> Charles DeRykus <> wrote:
    >>> Alternative if comma operator "ist nicht schoen bei mir".
    >>>
    >>> do {$frog="green"} and return if blort();

    >>
    >> I would say "and" is intrinsically fragile for this. In most cases in
    >> Perl, where you can use a constant, you can use an expression. ("use"
    >> is the only counterexample I thought of off the top of my head.)
    >>
    >> But not here:
    >>
    >> do { $frog = "green" } and return if blort();
    >>
    >> will always work, but
    >>
    >> do { $frog = $toad } and return if blort();
    >>
    >> will fail if $toad happens to have one of the Perl false values.

    >
    > I think I'd backstop it in non-trivial cases: do{ ... ;1}
    >>
    >> Either use comma, or make it a standard "if" block.

    >
    > The comma op is ok. Not in this example, but, a d'oh moment is
    > possible with a comma op too: ....,return or ....


    Did you ever inherit a relatively large body of code various people of
    varying competence-levels and copy'n'past-happiness worked on for some
    time? 'Accidental meanings', that is, code which doesn't make any
    literal sense and requires 'inside information' about the thoughts of
    the author while writing it (possibly shadowed by the fact that the bit
    in question is the 25th mutated copy of something which originally
    appeared in a totally different context) are a HUGE understanding
    impediment: Some guy who isn't you and possibly doesn't even know you
    won't a priori be aware of the fact that the do in

    do { $frog = 'green' } and return if blort()

    is a 'clever hack' supposed to silence a compiler warning which occurred
    because the compiler considered this a boolean expression instead of a
    'funky' sequencing construct. This would warrant a comment documenting
    it and then, things start to get really silly because that will end up
    as something

    # this is the wrong way but I like it
    do { $frog = 'green' } and return if blort()

    and it adds even more useless noise to the text.

    'Stubbornly refusing to listen'-story which has to be told in this
    context: Once upon a time in the past, I encountered a guy who
    complained about the technical inferiority of g++ (GNU C++-compiler)
    because it would usually abort with an out-of-memory-error when
    "compiling moderately large functions of only a few thousand lines". The
    idea that this could mean that his coding style was so far beyond
    anything resembling 'rhyme and reason' that nobody could imagine that
    the compiler would ever need to deal with something like that and that
    'structure your code' would be a brilliant solution to this problem
    apparently never occured to him.
     
    Rainer Weikusat, May 16, 2014
    #9
  10. Tim McDaniel

    John Black Guest

    In article <>,
    says...
    >
    > Did you ever inherit a relatively large body of code various people of
    > varying competence-levels and copy'n'past-happiness worked on for some
    > time? 'Accidental meanings', that is, code which doesn't make any
    > literal sense and requires 'inside information' about the thoughts of
    > the author while writing it (possibly shadowed by the fact that the bit
    > in question is the 25th mutated copy of something which originally
    > appeared in a totally different context) are a HUGE understanding
    > impediment:


    Words of wisdom suitable for framing...

    > 'Stubbornly refusing to listen'-story which has to be told in this
    > context: Once upon a time in the past, I encountered a guy who
    > complained about the technical inferiority of g++ (GNU C++-compiler)
    > because it would usually abort with an out-of-memory-error when
    > "compiling moderately large functions of only a few thousand lines". The
    > idea that this could mean that his coding style was so far beyond
    > anything resembling 'rhyme and reason' that nobody could imagine that
    > the compiler would ever need to deal with something like that and that
    > 'structure your code' would be a brilliant solution to this problem
    > apparently never occured to him.


    However, g++ should not abort with an out of memory error in this case. That's a big
    function but not unreasonably big (like a million lines of code).

    John Black
     
    John Black, May 16, 2014
    #10
  11. Tim McDaniel

    Dave Saville Guest

    On Fri, 16 May 2014 12:17:57 UTC, Rainer Weikusat
    <> wrote:

    > Did you ever inherit a relatively large body of code various people of
    > varying competence-levels and copy'n'past-happiness worked on for some
    > time?


    BTDTGTTS

    Two more senior than I programmers I worked with. One, who taught me
    BAL, started his variables at "a" - "z", then "aa" - "zz" then "aaa"
    You get the idea. Brilliant mathematician though.

    The other would make up what would appear to be a meaningful name in
    the context of the science - but wasn't. To this day I have never
    decided which was the worse to try and figure out. I think the latter
    because at least with the first you knew they were not related to
    anything and not go off on incorrect assumptions.

    Recently been involved in an project where the original authors were
    cut n paste happy. The lead programmer of today christened it "the
    curse of the duplicated code" due to somone in the past finding a bug
    and fixing N out of M copies. :-( N usually being *much* smaller
    than M.

    --
    Regards
    Dave Saville
     
    Dave Saville, May 16, 2014
    #11
  12. "Dave Saville" <> writes:

    [...]

    > Recently been involved in an project where the original authors were
    > cut n paste happy. The lead programmer of today christened it "the
    > curse of the duplicated code" due to somone in the past finding a bug
    > and fixing N out of M copies. :-( N usually being *much* smaller
    > than M.


    Related problem: "The Curse of the Mutated Manifold" --- a bunch of
    operations which are generally similar in nature, yet sufficiently
    different that no two manifest copies of the template code are actually
    identical, maybe with one or two which weren't copied from a common
    ancestor but implemented independently in a completely different way
    thrown in for good measure. Then, some non-trivial change has to be made
    to all of them ...

    It is usually possible to re-organize something like this into a class
    hierarchy with the bulk of the code going into the base class and
    subclasses overriding some 'generic operations' in order to provide
    their individual flavouring and IMHO, that's preferable to something
    like implementing (and testing and debugging) sixteen different
    'identical changes' in various places of the code.
     
    Rainer Weikusat, May 16, 2014
    #12
  13. On 5/16/2014 5:17 AM, Rainer Weikusat wrote:
    > Charles DeRykus <> writes:

    ..
    >> The comma op is ok. Not in this example, but, a d'oh moment is
    >> possible with a comma op too: ....,return or ....

    >
    > Did you ever inherit a relatively large body of code various people of
    > varying competence-levels and copy'n'past-happiness worked on for some
    > time? 'Accidental meanings', that is, code which doesn't make any
    > literal sense and requires 'inside information' about the thoughts of
    > the author while writing it (possibly shadowed by the fact that the bit
    > in question is the 25th mutated copy of something which originally
    > appeared in a totally different context) are a HUGE understanding
    > impediment: Some guy who isn't you and possibly doesn't even know you
    > won't a priori be aware of the fact that the do in
    >
    > do { $frog = 'green' } and return if blort()
    >
    > is a 'clever hack' supposed to silence a compiler warning which occurred
    > because the compiler considered this a boolean expression instead of a
    > 'funky' sequencing construct. This would warrant a comment documenting
    > it and then, things start to get really silly because that will end up
    > as something
    >
    > # this is the wrong way but I like it
    > do { $frog = 'green' } and return if blort()


    Through an extremist's prism, most of Perl's TIMTOWDI looks like a hack.
    They'll complain there's no need for "do" blocks or statement qualifiers
    for that matter... yuck! Not how "real coders" operate.

    To me a compiler warning doesn't equate to "wrong way". "Uninitialized
    value" warnings are routinely turned off. It doesn't warrant an apology
    or a comment or the slavish exclusivity of "if" blocks or comma op's as
    the "One True Way".

    OTOH, Larry say something like: "just because Perl gives you ten ways
    to do something, doesn't mean all of them are the best way". I can
    appreciate the view that even TIMTOWDI may get a bad rep if carried to
    extremes.

    --
    Charles DeRykus
     
    Charles DeRykus, May 17, 2014
    #13
  14. On 2014-05-15 20:36, Charles DeRykus <> wrote:
    > On 5/12/2014 3:46 PM, Tim McDaniel wrote:
    >> In article <>,
    >> Henry Law <> wrote:
    >>> $@ = "reset_user: invalid parameters\n" and return if $parms==1;

    [...]
    >>> Aside from explaining what I've misunderstood, what's the most Perlish
    >>> way to set a variable and return, all in one statement?

    >>
    >> Is there a problem with the comma operator?
    >> $frog = "green", return if blort();
    >>
    >> But personally I don't like flow of control in an expression, so I'd
    >> just write
    >> if (blort()) {
    >> $frog = "green";
    >> return;
    >> }
    >>

    >
    > Alternative if comma operator "ist nicht schoen bei mir".
    >
    > do {$frog="green"} and return if blort();
    >


    How about:

    do { $frog="green"; return } if blort();

    Avoids the problem with short-circuiting and, uses the braces to group
    together what belongs together and saves two key strokes ;-).

    Of course once you are there you might just use an ordinary if(){} as
    Tim suggested.

    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, May 17, 2014
    #14
  15. On 5/16/2014 11:05 PM, Peter J. Holzer wrote:
    > On 2014-05-15 20:36, Charles DeRykus <> wrote:
    >> On 5/12/2014 3:46 PM, Tim McDaniel wrote:
    >>> In article <>,
    >>> Henry Law <> wrote:
    >>>> $@ = "reset_user: invalid parameters\n" and return if $parms==1;

    > [...]
    >>>> Aside from explaining what I've misunderstood, what's the most Perlish
    >>>> way to set a variable and return, all in one statement?
    >>>
    >>> Is there a problem with the comma operator?
    >>> $frog = "green", return if blort();
    >>>
    >>> But personally I don't like flow of control in an expression, so I'd
    >>> just write
    >>> if (blort()) {
    >>> $frog = "green";
    >>> return;
    >>> }
    >>>

    >>
    >> Alternative if comma operator "ist nicht schoen bei mir".
    >>
    >> do {$frog="green"} and return if blort();
    >>

    >
    > How about:
    >
    > do { $frog="green"; return } if blort();
    >
    > Avoids the problem with short-circuiting and, uses the braces to group
    > together what belongs together and saves two key strokes ;-).
    >
    > Of course once you are there you might just use an ordinary if(){} as
    > Tim suted.
    >


    Tim wins then :) But one of the "TIMTOWDI fringe" may still turn up and
    say "Forget if{} ...I'll do it my way without an extra scope:"

    blort() and $frog="green" and return;

    --
    Charles DeRykus
     
    Charles DeRykus, May 17, 2014
    #15
  16. On 05/16/14 09:17, Dave Saville wrote:

    > Recently been involved in an project where the original authors were
    > cut n paste happy. The lead programmer of today christened it "the
    > curse of the duplicated code" due to somone in the past finding a bug
    > and fixing N out of M copies. :-( N usually being *much* smaller
    > than M.


    Yeah, that is frustrating. But I also see the opposite, where they
    write trivial a function used N times. And then changed the function
    because they need a different behavior in M places, where M << N.

    Xho
     
    Xho Jingleheimerschmidt, May 18, 2014
    #16
  17. Charles DeRykus <> writes:
    > On 5/16/2014 5:17 AM, Rainer Weikusat wrote:
    >> Charles DeRykus <> writes:

    > ..
    >>> The comma op is ok. Not in this example, but, a d'oh moment is
    >>> possible with a comma op too: ....,return or ....

    >>
    >> Did you ever inherit a relatively large body of code various people of
    >> varying competence-levels and copy'n'past-happiness worked on for some
    >> time? 'Accidental meanings', that is, code which doesn't make any
    >> literal sense and requires 'inside information' about the thoughts of
    >> the author while writing it (possibly shadowed by the fact that the bit
    >> in question is the 25th mutated copy of something which originally
    >> appeared in a totally different context) are a HUGE understanding
    >> impediment: Some guy who isn't you and possibly doesn't even know you
    >> won't a priori be aware of the fact that the do in
    >>
    >> do { $frog = 'green' } and return if blort()
    >>
    >> is a 'clever hack' supposed to silence a compiler warning which occurred
    >> because the compiler considered this a boolean expression instead of a
    >> 'funky' sequencing construct. This would warrant a comment documenting
    >> it and then, things start to get really silly because that will end up
    >> as something
    >>
    >> # this is the wrong way but I like it
    >> do { $frog = 'green' } and return if blort()

    >
    > Through an extremist's prism, most of Perl's TIMTOWDI looks like a
    > hack. They'll complain there's no need for "do" blocks or statement
    > qualifiers for that matter... yuck! Not how "real coders" operate.


    That's - at best - an unrelated general statement, at worst, a not so
    subtle way to suggest that people who aren't solipsists are a general
    danger (and ought to be burnt at the stake, persumably). What's that
    supposed to mean in the given context?

    > To me a compiler warning doesn't equate to "wrong way". "Uninitialized
    > value" warnings are routinely turned off. It doesn't warrant an
    > apology or a comment or the slavish exclusivity of "if" blocks or
    > comma op's as the "One True Way".


    and is a conditional operator supposed to evaluate its right hand
    operand when evaluating its left-hand operand yielded a true value.
    'comma' is a sequencing operator supposed to evaluate it's right-hand
    operand after evaluating its left-hand operand, regardless of the value
    that resulted in.

    $frog = 'green' and return if blort();

    causes a compiler warning because the compiler assumed, based on the
    fact that and was used despite the left-hand operand always evaluates to
    true, that someone might erroneously have used an assignment operator
    ('=') instead of a comparison operator ('=='), IOW, that the complex
    'unconditional' expression was meant to be a conditional
    expression. Considering that it wasn't, using an operator without this
    property, ie

    $frog = 'green', return if blort();

    seems like a pretty natural choice.
     
    Rainer Weikusat, May 18, 2014
    #17
  18. On 5/18/2014 5:50 AM, Rainer Weikusat wrote:
    ......
    >>>
    >>> # this is the wrong way but I like it
    >>> do { $frog = 'green' } and return if blort()

    >>
    >> Through an extremist's prism, most of Perl's TIMTOWDI looks like a
    >> hack. They'll complain there's no need for "do" blocks or statement
    >> qualifiers for that matter... yuck! Not how "real coders" operate.

    >
    > That's - at best - an unrelated general statement, at worst, a not so
    > subtle way to suggest that people who aren't solipsists are a general
    > danger (and ought to be burnt at the stake, persumably). What's that
    > supposed to mean in the given context?


    I reacted (or overreacted) to the comment "wrong way but I like it".
    Still use of the word "wrong" suggests a One-True-Way and those who
    utter that can be just as solipsistic as anyone else.

    >
    >> To me a compiler warning doesn't equate to "wrong way". "Uninitialized
    >> value" warnings are routinely turned off. It doesn't warrant an
    >> apology or a comment or the slavish exclusivity of "if" blocks or
    >> comma op's as the "One True Way".

    >

    ....
    >
    > $frog = 'green', return if blort();
    >
    > seems like a pretty natural choice.


    Amen... all's well in the church of TIMTOWDI.

    --
    Charles DeRykus
     
    Charles DeRykus, May 18, 2014
    #18
  19. Charles DeRykus <> writes:
    > On 5/18/2014 5:50 AM, Rainer Weikusat wrote:
    > .....
    >>>>
    >>>> # this is the wrong way but I like it
    >>>> do { $frog = 'green' } and return if blort()
    >>>
    >>> Through an extremist's prism, most of Perl's TIMTOWDI looks like a
    >>> hack. They'll complain there's no need for "do" blocks or statement
    >>> qualifiers for that matter... yuck! Not how "real coders" operate.

    >>
    >> That's - at best - an unrelated general statement, at worst, a not so
    >> subtle way to suggest that people who aren't solipsists are a general
    >> danger (and ought to be burnt at the stake, persumably). What's that
    >> supposed to mean in the given context?

    >
    > I reacted (or overreacted) to the comment "wrong way but I like it".
    > Still use of the word "wrong" suggests a One-True-Way and those who
    > utter that can be just as solipsistic as anyone else.


    Well, I still maintain that hiding the unconditional expression such
    that the compiler doesn't find it anymore instead of fixing the problem
    is 'wrong'.
     
    Rainer Weikusat, May 18, 2014
    #19
  20. Tim McDaniel

    Justin C Guest

    On 2014-05-17, Martijn Lievaart <> wrote:
    > On Fri, 16 May 2014 09:27:29 -0700, Jürgen Exner wrote:
    >
    >> "Dave Saville" <> wrote:
    >>>Recently been involved in an project where the original authors were cut
    >>>n paste happy. The lead programmer of today christened it "the curse of
    >>>the duplicated code"

    >>
    >> Oh come on. I am waaaaayyyyy more productive than you are, I produce 5
    >> times the number of lines of code.
    >> And lines of code is the only thing the bean counters and penny pinchers
    >> know how to measure .....

    >
    > My most productive sessions have a negative LOC count.


    Amen.

    Justin.

    --
    Justin C, by the sea.
     
    Justin C, May 19, 2014
    #20
    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. David Frauzel

    Operator precedence

    David Frauzel, May 13, 2004, in forum: Perl
    Replies:
    2
    Views:
    556
    Luc Van Hove
    May 17, 2004
  2. kbd

    Operator Precedence

    kbd, Jul 22, 2004, in forum: Java
    Replies:
    10
    Views:
    771
    Roedy Green
    Jul 27, 2004
  3. Master of C++
    Replies:
    4
    Views:
    748
    Karl Heinz Buchegger
    Feb 7, 2005
  4. Richard Bos

    && and || Operator precedence enforcement

    Richard Bos, Jan 19, 2004, in forum: C Programming
    Replies:
    18
    Views:
    627
    Dan Pop
    Jan 20, 2004
  5. Rainer Weikusat

    Re: Help with an operator precedence (?) puzzle

    Rainer Weikusat, May 15, 2014, in forum: Perl Misc
    Replies:
    0
    Views:
    74
    Rainer Weikusat
    May 15, 2014
Loading...

Share This Page