Alternative to use vars

Discussion in 'Perl Misc' started by Himal, Jul 2, 2003.

  1. Himal

    Himal Guest

    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.
    Himal, Jul 2, 2003
    #1
    1. Advertising

  2. Himal

    Greg Bacon Guest

    In article <>,
    Himal <> 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
    Greg Bacon, Jul 2, 2003
    #2
    1. Advertising

  3. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    (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/AwUBPwP472PeouIeTNHoEQIMhgCaA0q8GLANqUmBONt927YCbybDYpcAnjWA
    lPjLquQFXdiUHQFscjdsle4i
    =jZKd
    -----END PGP SIGNATURE-----
    Eric J. Roode, Jul 3, 2003
    #3
  4. Also sprach Eric J. Roode:

    > (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$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
    Tassilo v. Parseval, Jul 3, 2003
    #4
  5. Also sprach Martien Verbruggen:

    > On 3 Jul 2003 10:33:08 GMT,
    > Tassilo v. Parseval <> 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$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
    Tassilo v. Parseval, Jul 4, 2003
    #5
  6. On 4 Jul 2003 05:06:16 GMT,
    Tassilo v. Parseval <> wrote:
    > Also sprach Martien Verbruggen:
    >
    >> On 3 Jul 2003 10:33:08 GMT,
    >> Tassilo v. Parseval <> 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?
    |
    Martien Verbruggen, Jul 4, 2003
    #6
  7. Himal

    Bart Lateur Guest

    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.
    Bart Lateur, Jul 4, 2003
    #7
  8. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    "Tassilo v. Parseval" <> wrote in
    news:be10p4$m6m$-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-----
    Eric J. Roode, Jul 4, 2003
    #8
  9. 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 I´m 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:eek:^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@@
    Paul van Eldijk, Jul 4, 2003
    #9
  10. On Fri, 04 Jul 2003 15:01:33 +0200,
    Paul van Eldijk <> 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 I´m 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?
    Martien Verbruggen, Jul 5, 2003
    #10
  11. On Sat, 5 Jul 2003 10:26:54 +1000, Martien Verbruggen
    <> wrote:

    >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.


    Hmmm... this seems to be the main issue here. Maybe for a future Perl5
    release a (backwards compatible) mechanism might be devised, by means
    e.g. of a C<package> modifier, that gives a package an implicit
    lexical scope.


    Michele
    --
    $\=q.,.,$_=q.print' ,\g,,( w,a'c'e'h,,map{$_-=qif/g/;chr
    }107..q[..117,q)[map+hex,split//,join' ,2B,, w$ECDF078D3'
    F9'5F3014$,$,];];$\.=$/,s,q,32,g,s,g,112,g,y,' , q,,eval;
    Michele Dondi, Jul 5, 2003
    #11
  12. On Sat, 05 Jul 2003 21:24:48 +0200,
    Michele Dondi <> wrote:
    > On Sat, 5 Jul 2003 10:26:54 +1000, Martien Verbruggen
    ><> wrote:
    >
    >>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.

    >
    > Hmmm... this seems to be the main issue here. Maybe for a future Perl5
    > release a (backwards compatible) mechanism might be devised, by means
    > e.g. of a C<package> modifier, that gives a package an implicit
    > lexical scope.


    You can't do that. Not without major change.

    Packages can appear in multiple lexical scopes, and even in multiple
    files, simply by using the package keyword.

    $ cat Foo.pm
    package Foo;
    use vars qw/$bar/;
    $bar = 3;
    1;

    $ cat foo.pl
    #!/usr/local/bin/perl
    use warnings;
    use strict;

    use Foo;

    print "main: $Foo::bar\n";
    $Foo::bar = 5;

    package Foo;
    print "$bar\n";

    $ ./foo.pl
    main: 3
    5

    Yes, this is a pathological case, but so are all the cases presented in
    this argument. The problem of confusion simply doesn't exist in most of
    the code out there.

    I tend to think that C<our> is a much better solution than C<use vars>,
    because of things like this. There is nothing in foo.pl that indicates
    that $bar can be used unqualified. If there had been a C<use vars
    '$bar'> in that file in the main package, that would have been very
    confusing.

    If you need a lexical scope that is different from your file, you use a
    block.

    Martien
    --
    |
    Martien Verbruggen | Useful Statistic: 75% of the people make up
    | 3/4 of the population.
    |
    Martien Verbruggen, Jul 5, 2003
    #12
  13. On Sun, 6 Jul 2003 08:55:30 +1000, Martien Verbruggen
    <> wrote:

    >> Hmmm... this seems to be the main issue here. Maybe for a future Perl5
    >> release a (backwards compatible) mechanism might be devised, by means
    >> e.g. of a C<package> modifier, that gives a package an implicit
    >> lexical scope.

    >
    >You can't do that. Not without major change.


    Well, while I agree on *everything* you said hereafter, I have a doubt
    I didn't express myself clearly. Of course my idea is in any case
    highly speculative and may well be a very bad one indeed...

    What I was thinking of is a "modifier"[1] that applied to a package
    creates an "implicit pair of curly brackets, {}" around "all the stuff
    in that package. Suppose to call it "private"[2]; then the following
    portions of code would be equivalent:

    # portion 1
    private package mypackage;
    ....

    # portion 2
    {
    package my package;
    ...
    }

    At this point you may argue that writing a pair of curly brackets is
    easier than writing a keyword of a bunch of charachters. But as you
    know far better than me, a package can be a very long and complex
    beast and the use of "my" modifier might have some sense in such
    cases.


    [1] I hope it is the correct technical term.
    [2] I'm aware it's awful: hopefully a better name could be devised.


    Just my 2 Eurocents,
    Michele
    --
    $\=q.,.,$_=q.print' ,\g,,( w,a'c'e'h,,map{$_-=qif/g/;chr
    }107..q[..117,q)[map+hex,split//,join' ,2B,, w$ECDF078D3'
    F9'5F3014$,$,];];$\.=$/,s,q,32,g,s,g,112,g,y,' , q,,eval;
    Michele Dondi, Jul 7, 2003
    #13
  14. On Mon, 07 Jul 2003 11:49:02 +0200,
    Michele Dondi <> wrote:
    > On Sun, 6 Jul 2003 08:55:30 +1000, Martien Verbruggen
    ><> wrote:
    >
    >>> Hmmm... this seems to be the main issue here. Maybe for a future Perl5
    >>> release a (backwards compatible) mechanism might be devised, by means
    >>> e.g. of a C<package> modifier, that gives a package an implicit
    >>> lexical scope.

    >>
    >>You can't do that. Not without major change.

    >
    > Well, while I agree on *everything* you said hereafter, I have a doubt
    > I didn't express myself clearly. Of course my idea is in any case
    > highly speculative and may well be a very bad one indeed...
    >
    > What I was thinking of is a "modifier"[1] that applied to a package
    > creates an "implicit pair of curly brackets, {}" around "all the stuff
    > in that package. Suppose to call it "private"[2]; then the following
    > portions of code would be equivalent:
    >
    > # portion 1
    > private package mypackage;
    > ...
    >
    > # portion 2
    > {
    > package my package;
    > ...
    > }
    >
    > At this point you may argue that writing a pair of curly brackets is
    > easier than writing a keyword of a bunch of charachters. But as you
    > know far better than me, a package can be a very long and complex
    > beast and the use of "my" modifier might have some sense in such
    > cases.


    [It may be that I'm still misunderstanding what you're trying to say. If
    so, my apologies in advance...]

    I would indeed argue that if you want that scope (and that's of course a
    lexical scope) that it would be better to use implicit curlies. What I
    wanted to emphasise though, is that such a scope, with the curlies, is
    different from package scope. A package can exist in more than one
    lexical scope, and in fact often exist in more than one file. Package
    scope covers all of those lexical scopes. On the other hand, a lexical
    scope can also be larger than a package scope. If a variable is declared
    with my or our at the top of a file, and that file contains more than
    one package, the scope of that variable extends across the packages.

    The long and short of it is that package scope and lexical scope are
    orthogonal things. They do often overlap in real code, but behind the
    scenes there is no real overlap.


    From what you write, I wonder whether you mean that you'd like to have a
    "lexical" scope that would automatically spring to life when one is in a
    certain package. If so, then you're really talking about package scope,
    and you're looking for what C<use vars> does, I think. Allowing a real
    lexical scope[1] to extend like that would be, IMO, contrary to what a
    lexical scope is.

    In my view, the current state is quite the way it should be: If you need
    a package wide variable, use one. Name it by its fully qualified name,
    or use C<our> to lexically scope its short name[2]. If you need a
    lexical variable, create one with C<my>. If you need what C<use vars>
    does currently, explicitly mention the variable in each lexical scope
    you need it with C<our>.

    Alternatively, simply type C<no strict> and free yourself from the
    shackles :). In my opinion, all of the above, including the deprecation
    of C<use vars> lead to better coding practices, and easier to maintain,
    less bug-prone code. For me, that's a good reason to support it.

    Martien

    [1] One that would work with C<our> and C<my> scoped variables...

    [2] I would only do that to limit its scope, not to extend it beyond the
    package. When a variable is only needed once or twice, I use its full
    name.
    --
    |
    Martien Verbruggen | I took an IQ test and the results were
    | negative.
    |
    Martien Verbruggen, Jul 7, 2003
    #14
  15. On Mon, 7 Jul 2003 20:44:31 +1000, Martien Verbruggen
    <> wrote:

    >[It may be that I'm still misunderstanding what you're trying to say. If
    >so, my apologies in advance...]


    This is indeed possible, since english is not my native language and
    *my* english is far from perfect. However, still being relatively a
    newbie, this conversation is in any case useful for me.

    BTW: since you're so kind commenting my article, I'd like to hear your
    (and other's) opinion about the other post I wrote, namely the one
    about how naturally C<our> fits the existing scheme for "local"
    variables under the "natural-language-like-features-in-Perl point of
    view"...

    >I would indeed argue that if you want that scope (and that's of course a
    >lexical scope) that it would be better to use implicit curlies. What I
    >wanted to emphasise though, is that such a scope, with the curlies, is
    >different from package scope. A package can exist in more than one


    OK, I see the point *now*. So I might say at most that my
    (hypotetical) "solution" is a "first-order approximation" to package
    scope (with C<our>), isn't it? ("wouldn't it be?", that is)

    >The long and short of it is that package scope and lexical scope are
    >orthogonal things. They do often overlap in real code, but behind the
    >scenes there is no real overlap.


    Perfectly clear. So I guess there's no *simple* way, as I naively
    thought, to "link" them together by means of an "esoteric common
    vector", at least in Perl5. I wonder if in Perl6 they will actually be
    different aspects of the same underlying mechanism (I suppose that for
    backward compatibility the same apparent behaviour will be
    maintainded).

    >From what you write, I wonder whether you mean that you'd like to have a
    >"lexical" scope that would automatically spring to life when one is in a
    >certain package. If so, then you're really talking about package scope,


    This is (more or less) what I meant...

    >and you're looking for what C<use vars> does, I think. Allowing a real
    >lexical scope[1] to extend like that would be, IMO, contrary to what a
    >lexical scope is.


    Hmmm, I think I understand now. Thank you for the other detailed
    explanations, that I snipped.


    Michele
    --
    $\=q.,.,$_=q.print' ,\g,,( w,a'c'e'h,,map{$_-=qif/g/;chr
    }107..q[..117,q)[map+hex,split//,join' ,2B,, w$ECDF078D3'
    F9'5F3014$,$,];];$\.=$/,s,q,32,g,s,g,112,g,y,' , q,,eval;
    Michele Dondi, Jul 9, 2003
    #15
  16. On Wed, 09 Jul 2003 14:36:31 +0200,
    Michele Dondi <> wrote:
    > On Mon, 7 Jul 2003 20:44:31 +1000, Martien Verbruggen
    ><> wrote:


    > BTW: since you're so kind commenting my article, I'd like to hear your
    > (and other's) opinion about the other post I wrote, namely the one
    > about how naturally C<our> fits the existing scheme for "local"
    > variables under the "natural-language-like-features-in-Perl point of
    > view"...


    Is that the one with Message-ID
    <>?

    I read that article earlier, but I wasn't sure whether there was anythin
    in there that I could comment on :)

    I do think it might show that there is still a bit of a misunderstanding
    about what C<my()>, C<local()>, C<our()> and C<use vars> do, and that's
    understandable, since they seem to do many similar things.

    Maybe a few more explanations, as I see things, could help, in addition
    to MJD's "Coping with scoping" article. I'll say much of the same, but
    phrased differently.


    Perl has two types of variables: There are those that belong to a
    package, and those who don't. The ones that don't belong to a package
    are _created_ with C<my()>; all others belong to a package. The ones
    that don't belong to a package are only available inside of the lexical
    scope they are defined in, the others are available globally, which is
    why they are also often called global variables.

    Perl has two types of scope: lexical scope and "package scope", where
    the latter isn't really a scope, more a namespace. Lexical scope is
    (mainly) a compile time thing, and is defined by the enclosing block or
    file [1]. Package scope is defined by the use of the package keyword.

    Variables that don't belong to a package, i.e. the ones created with
    c<my()>, are often called lexical variables. This is fine, but it does
    introduce a bit of a confusion factor. The term lexical doesn't really
    apply to the variable, but only to its name. The name temporary or local
    variable would have been a better name[2], since these variables also
    cease to exist at the end of the current scope. However, Perl already
    had local (see later).

    Because lexical scope refers to the name of the variable, and not the
    variable itself you can have a lexically scoped package variable with
    C<our()>. The variable itself always exists and is accessible, it's just
    its short name that is only available in the current lexical scope. It's
    as if there is a temporary lexical variable that is an alias for the
    package variable[3].

    The C<use vars> pragma simply allows you to refer to the named variables
    by their short name while inside of the package name space (scope, if
    you want).

    All of the above work on variable names. Before the days of lexical
    variables the mechanism to localise variables was with C<local()>.
    However, C<local()> does not really localise a variable, but it
    localises a (package) variable value. The current value of the variable
    is saved, and restored at the end of the current scope. C<local()> has
    no effect on variable names. Nowadays, C<local()> has its main use in
    providing temporary values for the builtin variables, and is probably
    not the right solution for most other uses.

    So, summarising...

    C<my()> creates a new non-package variable with lexical scope, and
    existence.
    C<local()> saves the current value of a package (global) variable and
    restores it on leaving the current scope.
    C<our()> allows access to a package variable by its short name in the
    current lexical scope
    C<use vars> allows a variable to be referred to by its short name inside
    a package name space.

    One of these works with non-package variables, the other three with
    globals. Three of these work with (lexical) scopes, and one with package
    name spaces. Three of these act on variable names, and one on values
    only.

    >>The long and short of it is that package scope and lexical scope are
    >>orthogonal things. They do often overlap in real code, but behind the
    >>scenes there is no real overlap.

    >
    > Perfectly clear. So I guess there's no *simple* way, as I naively
    > thought, to "link" them together by means of an "esoteric common
    > vector", at least in Perl5. I wonder if in Perl6 they will actually be
    > different aspects of the same underlying mechanism (I suppose that for
    > backward compatibility the same apparent behaviour will be
    > maintainded).


    I haven't kept up with Perl 6 too well, but from what I understand a lot
    of this is one of the areas where some work will be done.

    Perl 6 will depart in many ways from the way things are done in Perl 5.
    There is no backward compatibility, except for a Perl5 to Perl 6
    translation, which will probably be automatic [4]. Perl 6 is a new language,
    and one of the goals of the project is to finally get rid of all the
    accumulated backward compatibility mess. Localisation and scope is
    actually not that messy, compared to many other things that are being
    cleaned up.

    Martien

    [1] It actually is defined by the location of the declaration up to the
    end of the enclosing block or file.

    [2] The term private variables, which is also expressed by C<my()> just
    doesn't entirely cut it for me, mainly because that expression is
    already in heavy use in OO, with a different sort of meaning.

    [3] I don't know whether that is how Perl implements it, which is why I
    say "as if".

    [4] As I said, I don't know too much about it, since I haven't been
    following the mailing lists very closely. I just browse them now and
    again.

    --
    |
    Martien Verbruggen | You can't have everything, where would you
    | put it?
    |
    Martien Verbruggen, Jul 10, 2003
    #16
  17. On Thu, 10 Jul 2003 10:36:29 +1000, Martien Verbruggen
    <> wrote:

    >> BTW: since you're so kind commenting my article, I'd like to hear your
    >> (and other's) opinion about the other post I wrote, namely the one

    >
    >Is that the one with Message-ID
    ><>?


    Yes, it is.

    >I read that article earlier, but I wasn't sure whether there was anythin
    >in there that I could comment on :)


    Fine!

    >I do think it might show that there is still a bit of a misunderstanding
    >about what C<my()>, C<local()>, C<our()> and C<use vars> do, and that's
    >understandable, since they seem to do many similar things.
    >
    >Maybe a few more explanations, as I see things, could help, in addition
    >to MJD's "Coping with scoping" article. I'll say much of the same, but
    >phrased differently.

    [snip]

    REPETITA IUVANT...

    >translation, which will probably be automatic [4]. Perl 6 is a new language,
    >and one of the goals of the project is to finally get rid of all the
    >accumulated backward compatibility mess. Localisation and scope is


    I see... actually, even if Perl is supposed to be a non-elegant (but
    magic!) language, whenever I discover *how* an extension to a previous
    release and in particular to Perl4 has been added, I'm astonished by
    how elegantly such an extension has been implemented wrt backwards
    compatibility.


    Michele
    --
    $\=q.,.,$_=q.print' ,\g,,( w,a'c'e'h,,map{$_-=qif/g/;chr
    }107..q[..117,q)[map+hex,split//,join' ,2B,, w$ECDF078D3'
    F9'5F3014$,$,];];$\.=$/,s,q,32,g,s,g,112,g,y,' , q,,eval;
    Michele Dondi, Jul 11, 2003
    #17
  18. Himal

    Greg Bacon Guest

    In article <bemqiq$bb9$>,
    David Combs <> wrote:

    : In article <>,
    : Michele Dondi <> wrote:
    :
    : >Another point that I wanted to discuss yesterday, but avoided to for
    : >various reasons, has to do with the well known
    : >natural-language-like-features-in-Perl issue: I read MJD's article on
    : >Perl's two mechanisms for local variables. I agree that they are
    :
    : What MJD article, ie, you know its title, maybe
    : even the url?

    Maybe "Seven Useful Uses of local"?

    http://perl.plover.com/local.html

    Greg
    --
    What are governments but great bands of thieves?
    -- St. Augustine
    Greg Bacon, Jul 12, 2003
    #18
  19. On Sat, 12 Jul 2003 12:20:20 -0000, (Greg Bacon)
    wrote:

    >: What MJD article, ie, you know its title, maybe
    >: even the url?
    >
    >Maybe "Seven Useful Uses of local"?
    >
    > http://perl.plover.com/local.html


    No, "Coping with scoping", at
    <http://perl.plover.com/FAQs/Namespaces.html>


    Michele
    --
    $\=q.,.,$_=q.print' ,\g,,( w,a'c'e'h,,map{$_-=qif/g/;chr
    }107..q[..117,q)[map+hex,split//,join' ,2B,, w$ECDF078D3'
    F9'5F3014$,$,];];$\.=$/,s,q,32,g,s,g,112,g,y,' , q,,eval;
    Michele Dondi, Jul 12, 2003
    #19
    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. Jon

    app vars and cache vars

    Jon, Dec 14, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    378
  2. Paul McGuire

    Idea for alternative use for @

    Paul McGuire, Aug 13, 2004, in forum: Python
    Replies:
    2
    Views:
    264
    Colin J. Williams
    Aug 13, 2004
  3. Linuxguy123
    Replies:
    7
    Views:
    664
    Paddy O'Loughlin
    Feb 20, 2009
  4. caccolangrifata
    Replies:
    18
    Views:
    383
    Chris Torek
    Jul 22, 2011
  5. ngoc

    Is use vars and our the same ?

    ngoc, Sep 5, 2005, in forum: Perl Misc
    Replies:
    1
    Views:
    80
    Anno Siegel
    Sep 5, 2005
Loading...

Share This Page