Useless use of a variable? 
Author Message
 Useless use of a variable?

[Posted and e-mailed.]

) # Variables
) if ($] < 5.6) {                    # Line 9
)     warn("Old perl...upgrade!\n");
)     use vars qw/ $opt_e $opt_c /;     # Line 11
) } else {
)     our $opt_e, $opt_c;               # Line 13
) }
[...]
) And the warnings produced (under perl 5.005_03) are:
)
) Use of reserved word "our" is deprecated at generate_rules line 13.
) Useless use of a variable in void context at generate_rules line 9.
) Old perl...upgrade!
)
) Obviously 5.005 dosn't understand our so the warning on line 13 makes
) sense but the warning about line 9 I don't understand (line 9 is the if
) ($] < 5.6) { line).
)
) The only variable used is $]. How is its use useless...?

The value returned by the C<if> block is the last value executed
in the C<if> block.  And at comile time Perl notes that line 13
might be the last statement and C<our $opt_e, $opt_c> is parsed
as C<$opt_c=>our(), $opt_c> so the useless use of variable is
referring to C<$opt_c> [you can verify this by making changes to
the code].  So it would be much better for Perl to report that
problem as being on line 13, but line 9 makes a slight bit of
sense.

But the real problem with your code is that you are trying to mix
compile-time and run-time constructs in an incompatible way.  I
vaguely recall a proposal for adding a warning for such code [I
searched but couldn't find the thread].

For example, line 11 is executed even on Perl 5.6 and above.

Here is the order in which the lines of your script are executed:

Prior to 5.6:
) #!/usr/bin/perl -w
) use strict;
) use Getopt::Std;
) use Net::IPv4Addr;
)     use vars qw/ $opt_e $opt_c /;
) if ($] < 5.6) {
)     warn("Old perl...upgrade!\n");
) getopt('e:c:');

5.6 and later:
) #!/usr/bin/perl -w
) use strict;
) use Getopt::Std;
) use Net::IPv4Addr;
)     use vars qw/ $opt_e $opt_c /;
)     our $opt_e, $opt_c;
) if ($] < 5.6) {
) getopt('e:c:');

You want something more like:

    # Variables
    BEGIN {
        if ($] < 5.6) {
            warn("Old perl...upgrade!\n");
            eval 'use vars qw/ $opt_e $opt_c /; 1'

        } else {
            eval 'our $opt_e, $opt_c; 1'

        }
    }

Note that this doesn't work if you want to conditionally use
C<my $opt_e, $opt_c> [or C<use strict>] since the C<my> would
lose effect at the end of the enclosing block.  Some possible
future solutions for this limitation have been discussed on
p5p, for example, see the thread on pragmas at:

http://www.*-*-*.com/
--
Tye McQueen    Nothing is obvious unless you are overlooking something
          http://www.*-*-*.com/ ~tye/ (scripts, links, nothing fancy)



Thu, 17 Oct 2002 03:00:00 GMT  
 Useless use of a variable?

Quote:

> if ($] < 5.6) {
>     warn("Old perl...upgrade!\n");
>     use vars qw/ $opt_e $opt_c /;
> } else {
>     our $opt_e, $opt_c;
> }
> And the warnings produced (under perl 5.005_03) are:

> Use of reserved word "our" is deprecated at generate_rules line 13.
> Useless use of a variable in void context at generate_rules line 9.

The keyword "our" was deprecated in 5.005 so as to make way for its use in
perl 5.6, which explains the first message. For the second, I'd guess that
perl got confused about the line number; it's the $opt_c which is in a
void context, on line 13. (Did you forget to put parens around the 'our'
list? 5.6 should catch that if you ask for that warning.)

Compile-time directives (such as 'use' and 'our') don't tend to work well
inside conditional statements like that. That's because the condition
won't be checked until run time.

If you want your code to work with 5.005 and 5.6 both, just use 'use vars'
in the traditional way. It'll be kept around for backwards compatibility
for a long time to come, I'm sure.

And in perl 5.6.0, the numeric value of $] is: 5.006! Surprise!

--
Tom Phoenix       Perl Training and Hacking       Esperanto
Randal Schwartz Case:     http://www.rahul.net/jeffrey/ovs/



Thu, 17 Oct 2002 03:00:00 GMT  
 Useless use of a variable?
) # Variables
) if ($] < 5.6) {
)     warn("Old perl...upgrade!\n");
)     use vars qw/ $opt_e $opt_c /;
) } else {
)     our $opt_e, $opt_c;
) }

And, unfortunately, I suggested:

)     # Variables
)     BEGIN {
)       if ($] < 5.6) {
)           warn("Old perl...upgrade!\n");
)           eval 'use vars qw/ $opt_e $opt_c /; 1'

)       } else {
)           eval 'our $opt_e, $opt_c; 1'

)       }
)     }
)
) Note that this doesn't work if you want to conditionally use
) C<my $opt_e, $opt_c>

Nor does it work for C<our>.  I was just about to look up whether
C<our> extends beyond a block's scope, which it doesn't, even
though it applies to global variables [a.k.a. "package variables"].

So I don't have a solution for you.

Also, you want C<our( $opt_e, $opt_c )>.
--
Tye McQueen    Nothing is obvious unless you are overlooking something
         http://www.metronet.com/~tye/ (scripts, links, nothing fancy)



Thu, 17 Oct 2002 03:00:00 GMT  
 Useless use of a variable?

Quote:
> You want something more like:

>     # Variables
>     BEGIN {
>    if ($] < 5.6) {
>        warn("Old perl...upgrade!\n");
>        eval 'use vars qw/ $opt_e $opt_c /; 1'

>    } else {
>        eval 'our $opt_e, $opt_c; 1'

>    }
>     }

Alas, that 'our' directive doesn't have the desired effect, for three
reasons. First, it fails to declare $opt_c, since there are no parens
around the list. But more importantly, it scopes those variables to the
eval, rather than the enclosing block! And even more importantly than
that, it's never reached, since (in Perl 5.6.0), the numeric value of $]
is 5.006.

Unless, of course, I'm missing something here....

--
Tom Phoenix       Perl Training and Hacking       Esperanto
Randal Schwartz Case:     http://www.rahul.net/jeffrey/ovs/



Thu, 17 Oct 2002 03:00:00 GMT  
 Useless use of a variable?
Hi,

I'm writing a script, only a few lines atm but it produces some warnings
I dont understand. The script reads:

#!/usr/bin/perl -w

# Libraries
use strict;
use Getopt::Std;
use Net::IPv4Addr;

# Variables
if ($] < 5.6) {
    warn("Old perl...upgrade!\n");
    use vars qw/ $opt_e $opt_c /;

Quote:
} else {

    our $opt_e, $opt_c;

Quote:
}

getopt('e:c:');

And the warnings produced (under perl 5.005_03) are:

Use of reserved word "our" is deprecated at generate_rules line 13.
Useless use of a variable in void context at generate_rules line 9.
Old perl...upgrade!

Obviously 5.005 dosn't understand our so the warning on line 13 makes
sense but the warning about line 9 I don't understand (line 9 is the if
($] < 5.6) { line).

The only variable used is $]. How is its use useless...?

Thanks,

Andrew



Fri, 18 Oct 2002 03:00:00 GMT  
 Useless use of a variable?

: Nor does it work for C<our>.  I was just about to look up whether
: C<our> extends beyond a block's scope, which it doesn't, even
: though it applies to global variables [a.k.a. "package variables"].

Question:

can you use

        our($xxx) if $something;

to avoid the block scope of

        if ($something)
        { #block scope starts
          our($xxx);
          #block scope ends
        }



Fri, 18 Oct 2002 03:00:00 GMT  
 Useless use of a variable?
)
) can you use
)
)       our($xxx) if $something;
)
) to avoid the block scope of
)
)       if ($something)
)       { #block scope starts
)         our($xxx);
)         #block scope ends
)       }

Do you mean:

    eval 'our($x)' if $something;

since, as we said before, putting a compile-time thing like C<our>
in a run-time conditional expression is worse than pointless.

But even:

    use strict;

    $x= $y;

gives:

    Global symbol "$x" requires explicit package name at - line 3.
    Global symbol "$y" requires explicit package name at - line 3.

because the C<eval> has its own scope [like an implicit block].

Any current solution for this is worse than just using C<use vars>.

For more sticky version compatibility problems, I've resorted to:

    if(  $] < 5  ) {
        die "This script requires perl 5 or newer";
    }
    undef $/;

    __END__
    #line 8
    # put the real script here
    1;

But this is pretty painful.  Splitting the code between files
works better, but adds its own set of pains.
--
Tye McQueen    Nothing is obvious unless you are overlooking something
         http://www.metronet.com/~tye/ (scripts, links, nothing fancy)



Fri, 18 Oct 2002 03:00:00 GMT  
 Useless use of a variable?

: )
: ) can you use
: )
: )     our($xxx) if $something;
: )
: ) to avoid the block scope of
: )
: )     if ($something)
: )     { #block scope starts
: )       our($xxx);
: )       #block scope ends
: )     }

: Do you mean:

:     eval 'our($x)' if $something;

: since, as we said before, putting a compile-time thing like C<our>

What I really meant was 'does an "if modifier" avoid the block scope' - a
question best answered my simple experiment - (the answer appears to be
Yes) - a question unrelated to this thread and hence a waste of anybodies
time.  In fact a similar test of "use" shows that
'use module if $condition' is a compile error.

However, it does make me think about the issue of the different
compilation phases, and what they mean.

E.g. consider code such as...

        if ($condition)
        {      
                use module;
        }

Compile time:

        use module

Run time:

        if ($condition)
        {
                -----------
        }

What, intuitively, goes in the ---- spot when the code is finally run?  Is
there any intuitive meaning to a block of code which is half invoked,
interupted by itself, and then completed later, after other parts of
itself get to run?

If the $condition turned out to be false, should the effects of the 'use'
command become unavailable - sort of like a database command being rolled
back?

imagine
        if ($onething)
        {
                use module1;
        }
        else #another
        {
                use module2;
        }

Should both semantics be available, and possibly two versions compiled,
and the version actually used determined at run time?

(Thanks moderator for allowing such divergencies to pass through to the
list.)



Fri, 18 Oct 2002 03:00:00 GMT  
 Useless use of a variable?

Quote:
> For more sticky version compatibility problems, I've resorted to:

>     if(  $] < 5  ) {
>    die "This script requires perl 5 or newer";
>     }
>     undef $/;

>     __END__
>     #line 8
>     # put the real script here
>     1;

> But this is pretty painful.  

I'll say! Trying to keep things back-back-backwards compatible with perl 4
is never pretty. But, if you must, here's a sweeter way:

    #!/usr/bin/perl -w

    # These two lines trap perl4
    $#_=${#_}; die "Upgrade that antique perl!\n"; __END__
    "%"}-1;

    use strict;
    print "I'm okay; I'm version $]!\n";

I'll leave the deconstruction to the fun of the reader. Enjoy!

--
Tom Phoenix       Perl Training and Hacking       Esperanto
Randal Schwartz Case:     http://www.rahul.net/jeffrey/ovs/



Fri, 18 Oct 2002 03:00:00 GMT  
 Useless use of a variable?

Quote:


}
} > if ($] < 5.6) {
} >     warn("Old perl...upgrade!\n");
} >     use vars qw/ $opt_e $opt_c /;
} > } else {
} >     our $opt_e, $opt_c;
} > }
}
} > And the warnings produced (under perl 5.005_03) are:
} >
} > Use of reserved word "our" is deprecated at generate_rules line 13.
} > Useless use of a variable in void context at generate_rules line 9.
}
} The keyword "our" was deprecated in 5.005 so as to make way for its use in
} perl 5.6, which explains the first message.

Just for the record, for us'uns running <5.6 Perls, what does/will 'our'
do.  A perldoc -f 'our' on my system gets me nothing...

Thanks!
  /Bernie\
--
Bernie Cosell                     Fantasy Farm Fibers

    -->  Too many people, too few sheep  <--          



Sat, 19 Oct 2002 03:00:00 GMT  
 Useless use of a variable?

Quote:

>} The keyword "our" was deprecated in 5.005 so as to make way for its use in
>} perl 5.6, which explains the first message.

>Just for the record, for us'uns running <5.6 Perls, what does/will 'our'
>do.  A perldoc -f 'our' on my system gets me nothing...

Perl is free.

You download it and unpack it and then you _do_ have the docs.   :-)

You do not need to install it to see the docs that come
with it (but you cannot use perldoc to look things up for
you, use some other tool).

----------------------------------
=item our EXPR

An C<our> declares the listed variables to be valid globals within
the enclosing block, file, or C<eval>.  That is, it has the same
scoping rules as a "my" declaration, but does not create a local
variable.  If more than one value is listed, the list must be placed
in parentheses.  The C<our> declaration has no semantic effect unless
"use strict vars" is in effect, in which case it lets you use the
declared global variable without qualifying it with a package name.
(But only within the lexical scope of the C<our> declaration.  In this
it differs from "use vars", which is package scoped.)

An C<our> declaration declares a global variable that will be visible
across its entire lexical scope, even across package boundaries.  The
package in which the variable is entered is determined at the point
of the declaration, not at the point of use.  This means the following
behavior holds:

    package Foo;
    our $bar;           # declares $Foo::bar for rest of lexical scope
    $bar = 20;

    package Bar;
    print $bar;         # prints 20

Multiple C<our> declarations in the same lexical scope are allowed
if they are in different packages.  If they happened to be in the same
package, Perl will emit warnings if you have asked for them.

    use warnings;
    package Foo;
    our $bar;           # declares $Foo::bar for rest of lexical scope
    $bar = 20;

    package Bar;
    our $bar = 30;      # declares $Bar::bar for rest of lexical scope
    print $bar;         # prints 30

    our $bar;           # emits warning
----------------------------------

--
    Tad McClellan                          SGML Consulting

    Fort Worth, Texas



Sat, 19 Oct 2002 03:00:00 GMT  
 Useless use of a variable?

Quote:

> Just for the record, for us'uns running <5.6 Perls, what does/will
> 'our' do.

It's analogous to 'my', for declaring variables, so the same syntax rules
apply.

    my $fred;                   # parens optional
    our $betty;                 # parens optional

    my($barney, $wilma);        # parens required
    our($pebbles, $bamm_bamm);  # parens required

The difference is that an 'our' variable is a global variable; it's part
of the current package. But the _name_ declared by 'our' is valid within a
lexical scope. This is useful along with 'use strict'.

    use strict;

    BEGIN {
        our $dino = 'arf';      # global variable,
                                # lexically-scoped name
        print "Dino is $dino.\n";
    }

    print "Dino is $dino.\n"; # 'strict vars' violation

    {
        our $dino;              # Same global as before
        print "Dino is $dino here, too.\n";
    }

In earlier perl, we used 'use vars' to declare globals. This had the
disadvantage of declaring them globally - once a variable has been seen in
'use vars', its use is permitted everywhere, even under 'strict vars'.

Does that give you what you need?

--
Tom Phoenix       Perl Training and Hacking       Esperanto
Randal Schwartz Case:     http://www.rahul.net/jeffrey/ovs/



Sat, 19 Oct 2002 03:00:00 GMT  
 Useless use of a variable?
Quote:


>> Just for the record, for us'uns running <5.6 Perls, what does/will 'our'
>> do.  A perldoc -f 'our' on my system gets me nothing...

>Same as 'use vars', but with a much nicer syntax.

 ^^^^
 ^^^^

Only "kind of" like 'use vars'.

It has different _semantics_.

   perldoc -f our

says:

   "...In this it differs from "use vars"..."

--
    Tad McClellan                          SGML Consulting

    Fort Worth, Texas



Sat, 19 Oct 2002 03:00:00 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Useless use of quotes around scalar variable

2. Unexplainable error: Useless use of private variable in void context

3. input fractions

4. Database Updates

5. Runtime 200 in delay, - How do I test for this fix on a slow cpu?

6. WEBSITE

7. Delphi 1 and TQuery

8. Tough (or stupid =) Q: Using a variable with a variable name

9. using contents of a scalar variable as a variable name

10. Using a variable as a variable name

11. using a variable as a variable name?

12. Using a variable to define a variable?

 

 
Powered by phpBB® Forum Software