Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Perl Misc (http://www.velocityreviews.com/forums/f67-perl-misc.html)
-   -   Alternative to use vars (http://www.velocityreviews.com/forums/t869885-alternative-to-use-vars.html)

Himal 07-02-2003 12:49 PM

Alternative to use vars
 
I am using
use vars qw ($scalar @array %hash);
in my program. I would like to know how to declare this in an
alternative way using our and EXPORT. I am not able to grasp what the
reference says about it.

Cheers,
Himal.

Greg Bacon 07-02-2003 01:14 PM

Re: Alternative to use vars
 
In article <365e1935.0307020449.7c4c16e9@posting.google.com >,
Himal <himal5@hotmail.com> wrote:

: I am using
: use vars qw ($scalar @array %hash);
: in my program. I would like to know how to declare this in an
: alternative way using our and EXPORT. I am not able to grasp what the
: reference says about it.

If you don't want to use the vars pragma, you could fully qualify
your values as in

$pkg::scalar = 3;
@pkg::array = qw/ apples oranges bananas /;
%pkg::hash = ();

where 'pkg' is the name of the package you want your variables to call
home. If you want the main package, you can abbreviate to $::scalar,
for example.

You can also declare the globals with our:

our $scalar;
our @array;
our %hash;

See the perlfunc documentation on our for details.

Hope this helps,
Greg
--
Arrogance is bliss.
-- Elizabeth L. Kaminsky

Eric J. Roode 07-03-2003 09:36 AM

Re: Alternative to use vars
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

gbacon@hiwaay.net (Greg Bacon) wrote in news:vg5mmas61oi489
@corp.supernews.com:

> You can also declare the globals with our:
>
> our $scalar;
> our @array;
> our %hash;
>
> See the perlfunc documentation on our for details.


Maybe I'm dense.... I have yet to grasp the advantage of 'our' over 'use
vars'.

- --
Eric
$_ = reverse sort qw p ekca lre Js reh ts
p, $/.r, map $_.$", qw e p h tona e; print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPwP472PeouIeTNHoEQIMhgCaA0q8GLANqUmBONt927YCby bDYpcAnjWA
lPjLquQFXdiUHQFscjdsle4i
=jZKd
-----END PGP SIGNATURE-----

Tassilo v. Parseval 07-03-2003 10:33 AM

Re: Alternative to use vars
 
Also sprach Eric J. Roode:

> gbacon@hiwaay.net (Greg Bacon) wrote in news:vg5mmas61oi489
> @corp.supernews.com:
>
>> You can also declare the globals with our:
>>
>> our $scalar;
>> our @array;
>> our %hash;
>>
>> See the perlfunc documentation on our for details.

>
> Maybe I'm dense.... I have yet to grasp the advantage of 'our' over 'use
> vars'.


You are not the only one trying to grasp that. The concept of lexically
scoped global (that is, dynamic) variables truely escapes me. The only
advantage I see is that you can introduce new global variables
everywhere easily like so:

our $var;
....
....
our $another_var;

Of course, 'use vars' can also be used multiple times. It's just a
little more to type.

Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus}) !JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexi ixesixeseg;y~\n~~dddd;eval

Tassilo v. Parseval 07-04-2003 05:06 AM

Re: Alternative to use vars
 
Also sprach Martien Verbruggen:

> On 3 Jul 2003 10:33:08 GMT,
> Tassilo v. Parseval <tassilo.parseval@rwth-aachen.de> wrote:


>> You are not the only one trying to grasp that. The concept of lexically
>> scoped global (that is, dynamic) variables truely escapes me. The only
>> advantage I see is that you can introduce new global variables
>> everywhere easily like so:

>
> You can limit (with our) where that global variable is accessible:


Yes, and this feels pretty unnatural to me. It remotely reminds me of
the strange scoping that PHP has...where you have to put a global()
before a variable if you want to use it in a particular function:

$var = "var";

function func() {
global $var;
print "var: $var\n";
}

I agree it's even more perverted in PHP because a block there can't
simply access variables that exists in the scope above.

> #!/usr/local/bin/perl
> use strict;
> use warnings;
>
> {
> use vars qw/$var/;
> $var = "var";
> our $our = "our";
>
> print "var: $var\n";
> print "our: $our\n";
> }
>
> print "var: $var\n";
> # print "our: $our\n"; # impossible
> sub_needing_global();
>
> sub sub_needing_global
> {
> our $our;
> print "our: $our\n";
> }

[...]
> In a single file, the same effect can be achieved with C<my>, but in
> multi-file projects that require a shared global, you can't use C<my>
> for the same purpose.


I don't think the above program could be rewritten with lexicals. Any
lexical declared in the upper bare block is lost once the block is left.

> Many people would say that it's better to avoid globals alltogether,
> but sometimes globals can make life a lot easier, and code much
> cleaner. In those cases, our is much preferable over C<use vars>
> because of the more finegrained control it gives you about the
> accessibility of that variable. It can prevent accidental access of
> globals in the same way that C<my> lexical scoping does.


And this is unlikely: You never really have many globals. Secondly, good
style demands that those global variables have a name that distinguishes
them from lexicals (like all uppercased). The danger of an accidental
access is therefore much lower than with lexicals of which you usually
have quite a bunch.

> C<use vars> is still deprecated, so it's probably better (unless you
> have to write code for 5.005) to not use it anymore.


I was lately busy making Perl5.00503 (the one that comes with FreeBSD 4.7)
work with the current autoconf package. It required a more recent
File::Copy module. I took this module from a 5.8.0 release and of
course, because of our(), it didn't work out of the box. It was easy to
fix because the finer grain of control that our() offers wasn't used.
And this seems to be the whole point: I haven't yet found any code in
the wild that made use of it. Usually it's used as a drop-in replacement
for 'use vars' with the exact same semantics.

I am really fearing the moment when 'use vars' will trigger a deprecated
warning in one of the future Perl5 releases. This will be the point
where you have to start to package-qualify all globals if you want to
write a module which is backwards compatible to at least 5.005.

Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus}) !JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexi ixesixeseg;y~\n~~dddd;eval

Martien Verbruggen 07-04-2003 06:11 AM

Re: Alternative to use vars
 
On 4 Jul 2003 05:06:16 GMT,
Tassilo v. Parseval <tassilo.parseval@rwth-aachen.de> wrote:
> Also sprach Martien Verbruggen:
>
>> On 3 Jul 2003 10:33:08 GMT,
>> Tassilo v. Parseval <tassilo.parseval@rwth-aachen.de> wrote:

>
>>> You are not the only one trying to grasp that. The concept of lexically
>>> scoped global (that is, dynamic) variables truely escapes me. The only
>>> advantage I see is that you can introduce new global variables
>>> everywhere easily like so:

>>
>> You can limit (with our) where that global variable is accessible:

>
> Yes, and this feels pretty unnatural to me. It remotely reminds me of
> the strange scoping that PHP has...where you have to put a global()
> before a variable if you want to use it in a particular function:


It doesn't feel unnatural to me. But I guess that's a matter of
personal preference :)

[snip of program]

> [...]
>> In a single file, the same effect can be achieved with C<my>, but in
>> multi-file projects that require a shared global, you can't use C<my>
>> for the same purpose.

>
> I don't think the above program could be rewritten with lexicals. Any
> lexical declared in the upper bare block is lost once the block is left.


I meant that if you declare a my() variable at file scope, it'd be
available through the whole file, acting a bit as a global, but not
actually being a global. I agree that my wording did not at all
express what I meant :)

>> Many people would say that it's better to avoid globals alltogether,
>> but sometimes globals can make life a lot easier, and code much
>> cleaner. In those cases, our is much preferable over C<use vars>
>> because of the more finegrained control it gives you about the
>> accessibility of that variable. It can prevent accidental access of
>> globals in the same way that C<my> lexical scoping does.

>
> And this is unlikely: You never really have many globals. Secondly, good
> style demands that those global variables have a name that distinguishes
> them from lexicals (like all uppercased). The danger of an accidental
> access is therefore much lower than with lexicals of which you usually
> have quite a bunch.


And, indeed, when I write brand new code, that's more or less the
strategy I follow. However, sometimes one needs to work with old
code, that was written by people who didn't understand the value of
limiting scope. Rather than rewriting the whole thing to have a clean
base, it's often easier just to accept what's there, and to add the
new functionality required, but this time trying to keep it clean. We
all know that next week we will have a chance to rewrite it to our
liking :)

Martien
--
|
Martien Verbruggen |
Trading Post Australia | Hi, Dave here, what's the root password?
|

Bart Lateur 07-04-2003 08:29 AM

Re: Alternative to use vars
 
Martien Verbruggen wrote:

>> You are not the only one trying to grasp that. The concept of lexically
>> scoped global (that is, dynamic) variables truely escapes me. The only
>> advantage I see is that you can introduce new global variables
>> everywhere easily like so:

>
>You can limit (with our) where that global variable is accessible:


The part that makes no sense to me, is how use of these var now crosses
package boundaries...

$Bar::x = 123;
package Foo;
our $x = "abc";
package Bar;
print $x;

Guess what that'll print?

--
Bart.

Eric J. Roode 07-04-2003 11:47 AM

Re: Alternative to use vars
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de> wrote in
news:be10p4$m6m$1@nets3.rz.RWTH-Aachen.DE:

> Also sprach Eric J. Roode:
>
>> Maybe I'm dense.... I have yet to grasp the advantage of 'our' over
>> 'use vars'.

>
> You are not the only one trying to grasp that.


Oh good, I'm glad I'm not the only one :-)

- --
Eric
$_ = reverse sort qw p ekca lre Js reh ts
p, $/.r, map $_.$", qw e p h tona e; print

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPwVpNmPeouIeTNHoEQJ6IQCfcwah2/v88iJeVY4dBWyVwQ3U19IAnjLb
I14yeyTv7IGNWZSHaQ20cvAb
=Le5p
-----END PGP SIGNATURE-----

Paul van Eldijk 07-04-2003 01:01 PM

Re: Alternative to use vars
 
On Fri, 04 Jul 2003 08:29:58 +0000 Bart Lateur wrote:

> Martien Verbruggen wrote:
>
>>> You are not the only one trying to grasp that. The concept of lexically
>>> scoped global (that is, dynamic) variables truely escapes me. The only
>>> advantage I see is that you can introduce new global variables
>>> everywhere easily like so:

>>
>>You can limit (with our) where that global variable is accessible:

>
> The part that makes no sense to me, is how use of these var now crosses
> package boundaries...
>
> $Bar::x = 123;
> package Foo;
> our $x = "abc";
> package Bar;
> print $x;
>
> Guess what that'll print?


However, if you change it to
$Bar::x = 123;
package Foo;
use vars qw($x);
$x = "abc";
package Bar;
print $x;

you get the expected result. I guess Im confued too....


Paul

--
$_=q{ ^4;c;14;1b:a^5;16:c^17:e^a;11;19:h^9;15:j^0:k^18:l ^13
:n^6:o^7:p^10:r^b;12;1a:s^2:t^3;8:u^1};s{(?<=[;^])(\d)?([\d
abc])}{$a=$1;$2=~/([abc])/?$a*13+ord($1)%87:$1*13+$2}egx;
for(split/:/){($a,@_)=split/[;^]/;@@[@_]=($a)x@_}print@@


Martien Verbruggen 07-05-2003 12:26 AM

Re: Alternative to use vars
 
On Fri, 04 Jul 2003 15:01:33 +0200,
Paul van Eldijk <rev_1318@hotmail.com> wrote:
> On Fri, 04 Jul 2003 08:29:58 +0000 Bart Lateur wrote:
>
>> Martien Verbruggen wrote:
>>
>>>> You are not the only one trying to grasp that. The concept of lexically
>>>> scoped global (that is, dynamic) variables truely escapes me. The only
>>>> advantage I see is that you can introduce new global variables
>>>> everywhere easily like so:
>>>
>>>You can limit (with our) where that global variable is accessible:

>>
>> The part that makes no sense to me, is how use of these var now crosses
>> package boundaries...
>>
>> $Bar::x = 123;
>> package Foo;
>> our $x = "abc";
>> package Bar;
>> print $x;


[note that this is strict-safe]

>> Guess what that'll print?


It'll print whatever is in the second $x, because that's where the scope
of that $x extends to. While this is also an effect of C<our>, I don't
like this bit of it. I (very rarely) use our to control the scope of a
global in the other direction, but I've never used it to extend the
scope like this.

> However, if you change it to
> $Bar::x = 123;
> package Foo;
> use vars qw($x);
> $x = "abc";
> package Bar;
> print $x;


[note that this is not strict-safe]

> you get the expected result. I guess Im confued too....


This is what the difference between C<our> and C<use vars> is. C<our>
works on lexical scopes, and C<use vars> works on package scope.

C<our> and C<use vars> do not work in the same way. However, for almost
all of the cases of C<use vars> I have ever seen [1], C<our> can be used
instead. In fact, I don't think that there is any strict-safe historical
code, where C<use vars> cannot be simply replaced with C<our>. I can
think of many non-strict safe examples, like the above, but that's
unlikely to ever occur in real code, since C<use vars> wouldn't have
been needed without C<use strict 'vars'>.

So, unless someone can come up with an example with C<use strict> and
C<use vars>, that behaves differently when C<use vars> is replaced with
C<our>, I'd say that C<our> does a good job at replacing C<use vars>, as
it was used, and adds some new scoping rules, that shouldn't present you
with any surprises in code that used to work.

The only time you'll get surprises is in the case of the above-quoted
code example, which requires strictures to not be in force in the
historical version. C<use vars> was always intended to be used with
C<use strict 'vars'> in place, because it circumvents one of the
requirements that C<use strict 'vars'> imposes.

Martien

[1] All cases in real code. The cases that I've seen where a straight
replacement does not work are all in postings to Usenet.
--
|
Martien Verbruggen | Since light travels faster than sound, isn't
| that why some people appear bright until you
| hear them speak?


All times are GMT. The time now is 03:10 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.