if statement oddity

Discussion in 'Perl Misc' started by Jens Luedicke, Mar 25, 2005.

  1. Hiya..

    I encountered a strange problem with an if () statement:

    if ((my $r = &{$self->{onFile}}($path) != SUCCESS)) {
    return $r;
    }

    The above code seems to ignore the return value of the function
    and somehow overrides it. the return value of the called function
    returns FAILED, but $r doesn't reflect that!?

    The following code, works as expected:

    my $r = &{$self->{onFile}}($path);

    if ($r != SUCCESS)) {
    return $r;
    }

    fyi, SUCCESS is a constant. use constant SUCCESS => 1;

    both code examples should work the same. no matter what!?

    do I miss something? I'm a little disturbed right now.


    jens

    --
    Jens Luedicke
    web: http://perldude.de
    Jens Luedicke, Mar 25, 2005
    #1
    1. Advertising

  2. Jens Luedicke wrote:
    > I encountered a strange problem with an if () statement:
    >
    > if ((my $r = &{$self->{onFile}}($path) != SUCCESS)) {
    > return $r;
    > }
    >
    > The above code seems to ignore the return value of the function
    > and somehow overrides it. the return value of the called function
    > returns FAILED, but $r doesn't reflect that!?


    How about enabling warnings? Using the string 'FAILED' in a numerical
    comparison isn't very wise.

    But the behaviour is about precedence. The return value of the function
    is compared with the SUCCESS constant, and $r is assigned the bolean
    value resulting from that comparison. This should do what you want:

    if ( ( my $r = &{$self->{onFile}}($path) ) ne SUCCESS ) {
    return $r;
    }

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
    Gunnar Hjalmarsson, Mar 25, 2005
    #2
    1. Advertising

  3. On 25/03/2005, Jens Luedicke wrote:

    > if ((my $r = &{$self->{onFile}}($path) != SUCCESS)) {
    > return $r;
    > }


    [...]

    > my $r = &{$self->{onFile}}($path);
    >
    > if ($r != SUCCESS)) {
    > return $r;
    > }


    [...]

    > both code examples should work the same. no matter what!?
    > do I miss something? I'm a little disturbed right now.



    Look up the operator precedence rules at the top of

    perldoc perlop

    (!= is evaluated before =)

    --
    felix
    Felix Geerinckx, Mar 25, 2005
    #3
  4. Gunnar Hjalmarsson wrote:

    > How about enabling warnings? Using the string 'FAILED' in a numerical
    > comparison isn't very wise.


    I use warnings.

    FAILED and SUCCESS are numerical constants.

    the specific code is on the Filer/DirWalk.pm module of my Filer program.

    > But the behaviour is about precedence. The return value of the function
    > is compared with the SUCCESS constant, and $r is assigned the bolean
    > value resulting from that comparison. This should do what you want:
    >
    > if ( ( my $r = &{$self->{onFile}}($path) ) ne SUCCESS ) {
    > return $r;
    > }
    >


    using 'ne' doesn't make a difference and wouldn't be practical in a
    numerical comparison.

    to avoid problems with precedence the assignment is enclosed in
    parentheses. so the assignment should hbe evaluated first and its return
    value compared afterwards. At least that's what I expect.


    --
    Jens Luedicke
    web: http://perldude.de
    Jens Luedicke, Mar 25, 2005
    #4
  5. Jens Luedicke

    Paul Lalli Guest

    Jens Luedicke originally wrote:
    > Hiya..
    >
    > I encountered a strange problem with an if () statement:
    >
    > if ((my $r = &{$self->{onFile}}($path) != SUCCESS)) {
    > return $r;
    > }
    >


    Jens Luedicke then later wrote:
    > to avoid problems with precedence the assignment is enclosed in
    > parentheses. so the assignment should hbe evaluated first and its return
    > value compared afterwards. At least that's what I expect.



    Exactly where in your code are you using parentheses around the
    assignment? You're enclosing the entire if statement in parentheses,
    not any particular part of it.

    Paul Lalli
    Paul Lalli, Mar 25, 2005
    #5
  6. On 25/03/2005, Jens Luedicke wrote:

    > to avoid problems with precedence the assignment is enclosed in
    > parentheses. so the assignment should hbe evaluated first and its
    > return value compared afterwards. At least that's what I expect.


    Look at your code (copied from your original post for reference):

    > if ((my $r = &{$self->{onFile}}($path) != SUCCESS)) {
    > return $r;
    > }


    The assignment isn't enclosed in parentheses. The full statement is
    enclosed in double parentheses.

    --
    felix
    Felix Geerinckx, Mar 25, 2005
    #6
  7. Felix Geerinckx wrote:

    >
    > The assignment isn't enclosed in parentheses. The full statement is
    > enclosed in double parentheses.
    >


    shit. little typo. big confusion.

    mea culpa! shame on me...

    /me hides

    --
    Jens Luedicke
    web: http://perldude.de
    Jens Luedicke, Mar 25, 2005
    #7
  8. Jens Luedicke wrote:

    > Hiya..
    >
    > I encountered a strange problem with an if () statement:
    >
    > if ((my $r = &{$self->{onFile}}($path) != SUCCESS)) {
    > return $r;
    > }
    >
    > The above code seems to ignore the return value of the function
    > and somehow overrides it. the return value of the called function
    > returns FAILED, but $r doesn't reflect that!?


    Er? Assuming FAILED != SUCCESS then $r will be set to false. I can't
    recell off the top of my head which false but since it immediately goes
    out of scope this doesn't matter.


    >
    > The following code, works as expected:
    >
    > my $r = &{$self->{onFile}}($path);
    >
    > if ($r != SUCCESS)) {
    > return $r;
    > }


    No, that contains a syntax error and will not compile.

    > fyi, SUCCESS is a constant. use constant SUCCESS => 1;
    >
    > both code examples should work the same. no matter what!?
    >
    > do I miss something? I'm a little disturbed right now.


    I'm betting you meant

    if ((my $r = &{$self->{onFile}}($path)) != SUCCESS) {
    return $r;
    }

    Can I suggest that in future you produce a _minimal_ but _complete_
    example that you have actually run and found to behave as you don't
    expect. Post it together with a precices description of what it did and
    what you expected.

    This advice and much other useful advice can be found in the posting
    guidelines.
    Brian McCauley, Mar 25, 2005
    #8
  9. Jens Luedicke <> wrote:

    > I encountered a strange problem with an if () statement:


    [snip]

    > do I miss something?



    Yes.

    You missed posting a short and complete program that we can run
    that illustrates the problem you are having.


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Mar 25, 2005
    #9
  10. Jens Luedicke wrote:
    > Gunnar Hjalmarsson wrote:
    >> How about enabling warnings? Using the string 'FAILED' in a numerical
    >> comparison isn't very wise.

    >
    > I use warnings.


    Good.

    > FAILED and SUCCESS are numerical constants.


    I see. But you failed to explain that as regards FAILED.

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
    Gunnar Hjalmarsson, Mar 25, 2005
    #10
  11. Brian McCauley wrote:
    > Jens Luedicke wrote:
    >>
    >> if ((my $r = &{$self->{onFile}}($path) != SUCCESS)) {
    >> return $r;
    >> }

    >
    > Er? Assuming FAILED != SUCCESS then $r will be set to false.


    Suppose you mean true, i.e. 1.

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
    Gunnar Hjalmarsson, Mar 25, 2005
    #11
  12. Gunnar Hjalmarsson wrote:

    > Brian McCauley wrote:
    >
    >> Jens Luedicke wrote:
    >>
    >>>
    >>> if ((my $r = &{$self->{onFile}}($path) != SUCCESS)) {
    >>> return $r;
    >>> }

    >>
    >>
    >> Er? Assuming FAILED != SUCCESS then $r will be set to false.

    >
    >
    > Suppose you mean true, i.e. 1.


    Yes I mean true.
    Brian McCauley, Mar 25, 2005
    #12
    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. Replies:
    3
    Views:
    518
  2. Edwin Knoppert
    Replies:
    0
    Views:
    368
    Edwin Knoppert
    Dec 29, 2005
  3. nooobody

    bean reflection oddity

    nooobody, Feb 20, 2005, in forum: Java
    Replies:
    4
    Views:
    623
    nooobody
    Feb 20, 2005
  4. Remon van Vliet

    Oddity in ByteBuffer code?

    Remon van Vliet, May 19, 2005, in forum: Java
    Replies:
    5
    Views:
    439
    Chris Uppal
    May 20, 2005
  5. hiwa

    XMLEncoder oddity

    hiwa, Oct 7, 2005, in forum: Java
    Replies:
    16
    Views:
    10,419
Loading...

Share This Page