Unexpected subroutine behaviour without &

Discussion in 'Perl Misc' started by Kevin Collins, Jun 2, 2004.

  1. Hi,

    I've just stumbled across a strange problem on my HP-UX systems. The
    following code will demonstrate the problem:

    #!/usr/bin/perl -w

    use strict;
    use warnings;

    my @list = qw(cc aa bb aa dd zz ee);
    print join(" ", sort(UniqArray(@list))) . "\n";
    print join(" ", sort(&UniqArray(@list))) . "\n";

    sub UniqArray
    {
    # This function takes an array reference and returns
    # an array without dups

    # local variables
    my %tmp;
    my @returns;

    foreach (@list)
    {
    # if the hash element has a value, then don't
    # add it to return list since we've already added it
    push (@returns, $_) unless ($tmp{$_});
    $tmp{$_}++;
    }

    return @returns;
    }

    I have two different "home built" versions of Perl (5.6.1 and 5.8.0) and two
    HP-supplied versions (5.6.1 and 5.8.0).

    The output I would expect:

    aa bb cc dd ee zz
    aa bb cc dd ee zz

    However, here is what I see:

    Custom 5.6.1:

    ee zz dd aa bb aa cc
    aa bb cc dd ee zz

    Custom 5.8.0:

    ee zz dd aa bb aa cc
    aa bb cc dd ee zz

    HP's 5.6.1:

    ee zz dd aa bb aa cc
    aa bb cc dd ee zz

    HP's 5.8.0:

    aa bb cc dd ee zz
    aa bb cc dd ee zz

    I also checked Perl 5.8.0 on RedHat 9.0 and see my expected results. I'm
    wondering why I need to call &UniqArray(@list) instead of UniqArray(@list)? I
    started looking into this when a new script was not giving me a correctly
    sorted list. Is there some know issue with this?

    Thanks,

    Kevin
    Kevin Collins, Jun 2, 2004
    #1
    1. Advertising

  2. Kevin Collins wrote:
    > I've just stumbled across a strange problem on my HP-UX systems.
    > The following code will demonstrate the problem:
    >
    > #!/usr/bin/perl -w


    Why the -w switch? "use warnings;" is enough.

    > my @list = qw(cc aa bb aa dd zz ee);
    > print join(" ", sort(UniqArray(@list))) . "\n";


    Considering the code in UniqArray(), you could as well just say:

    print join(" ", sort UniqArray()) . "\n";

    > sub UniqArray
    > {
    > # This function takes an array reference


    No, it doesn't. It takes the array @list, which is a package lexical.
    The list in @_, which contains copies of the elements in @list since
    you passed the array (not array reference) @list, is not used.

    > I'm wondering why I need to call &UniqArray(@list) instead of
    > UniqArray(@list)?


    Can't explain that.

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

  3. Kevin Collins <> wrote:

    > print join(" ", sort(UniqArray(@list))) . "\n";

    ^^^^^

    That might as well not be there, UniqArray() never examines its arguments.


    > sub UniqArray
    > {


    > foreach (@list)



    You should not communicate with subroutines via global variables,
    you should pass arguments instead.


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
    Tad McClellan, Jun 2, 2004
    #3
  4. Gunnar Hjalmarsson <> wrote:

    > Kevin Collins wrote:


    >> sub UniqArray
    >> {
    >> # This function takes an array reference

    >
    > No, it doesn't. It takes the array @list, which is a package
    > lexical. The list in @_, which contains copies of the elements in
    > @list since you passed the array (not array reference) @list, is
    > not used.


    It could be a bit shorter, too.

    sub UniqArray {
    # This function takes an array reference and returns
    # an array without dups

    my %seen;
    return grep {not $seen{$_}++} @{$_[0]};
    }

    >> I'm wondering why I need to call &UniqArray(@list) instead of
    >> UniqArray(@list)?

    >
    > Can't explain that.


    Me neither.
    David K. Wall, Jun 2, 2004
    #4
  5. In article <>, Gunnar Hjalmarsson wrote:
    > Kevin Collins wrote:
    >> I've just stumbled across a strange problem on my HP-UX systems.
    >> The following code will demonstrate the problem:
    >>
    >> #!/usr/bin/perl -w

    >
    > Why the -w switch? "use warnings;" is enough.


    True - I added the "use warnings" to the script because I was running:

    /some/path/to/perl myscript
    /some/other/path/to/perl myscript

    and wanted to make sure I had warnings enabled (with using -w on the command
    line).

    >> my @list = qw(cc aa bb aa dd zz ee);
    >> print join(" ", sort(UniqArray(@list))) . "\n";

    >
    > Considering the code in UniqArray(), you could as well just say:
    >
    > print join(" ", sort UniqArray()) . "\n";


    Damn - I hate it when I blunder a code post! I incorrectly posted the wrong
    version of my test code. That foreach line should be:

    foreach (@_)


    >> sub UniqArray
    >> {
    >> # This function takes an array reference

    >
    > No, it doesn't. It takes the array @list, which is a package lexical.
    > The list in @_, which contains copies of the elements in @list since
    > you passed the array (not array reference) @list, is not used.
    >
    >> I'm wondering why I need to call &UniqArray(@list) instead of
    >> UniqArray(@list)?

    >
    > Can't explain that.
    >
    Kevin Collins, Jun 2, 2004
    #5
  6. Kevin Collins

    Ben Morrow Guest

    Quoth Kevin Collins <>:
    > Hi,
    >
    > I've just stumbled across a strange problem on my HP-UX systems. The
    > following code will demonstrate the problem:
    >
    > #!/usr/bin/perl -w
    >
    > use strict;
    > use warnings;
    >
    > my @list = qw(cc aa bb aa dd zz ee);
    > print join(" ", sort(UniqArray(@list))) . "\n";
    > print join(" ", sort(&UniqArray(@list))) . "\n";
    >
    > sub UniqArray
    > {
    > # This function takes an array reference and returns
    > # an array without dups
    >
    > # local variables
    > my %tmp;
    > my @returns;
    >
    > foreach (@list)


    Well, there's a bug here. You are accessing the global @list directly;
    what you mean is

    for (@_) {

    This makes no difference though...

    > {
    > # if the hash element has a value, then don't
    > # add it to return list since we've already added it
    > push (@returns, $_) unless ($tmp{$_});
    > $tmp{$_}++;
    > }
    >
    > return @returns;
    > }
    >
    > I have two different "home built" versions of Perl (5.6.1 and 5.8.0) and two
    > HP-supplied versions (5.6.1 and 5.8.0).
    >
    > The output I would expect:
    >
    > aa bb cc dd ee zz
    > aa bb cc dd ee zz
    >
    > However, here is what I see:
    >
    > Custom 5.6.1:
    >
    > ee zz dd aa bb aa cc
    > aa bb cc dd ee zz
    >
    > Custom 5.8.0:
    >
    > ee zz dd aa bb aa cc
    > aa bb cc dd ee zz
    >
    > HP's 5.6.1:
    >
    > ee zz dd aa bb aa cc
    > aa bb cc dd ee zz
    >
    > HP's 5.8.0:
    >
    > aa bb cc dd ee zz
    > aa bb cc dd ee zz
    >
    > I also checked Perl 5.8.0 on RedHat 9.0 and see my expected results.


    Using

    This is perl, v5.8.2 built for i686-linux-thread-multi

    I get the following results:

    #!/usr/bin/perl -l

    my @list = qw/cc aa bb aa dd zz ee/;

    sub uniq {
    my (@r, %t);

    # print "ARGS:", @_;

    for (@_) {
    push @r, $_ unless $t{$_};
    $t{$_}++;
    }

    return @r;
    }

    print sort uniq @list;
    print sort uniq(@list);
    print sort(uniq @list);
    print sort(uniq(@list));
    print sort &uniq(@list);

    __END__

    ee zz dd aa bb aa cc
    ee zz dd aa bb aa cc
    ee zz dd aa bb aa cc
    aa bb cc dd ee zz
    aa bb cc dd ee zz

    Uncommenting the 'print "ARGS:"' line makes it clear what is happening:
    in the first three cases, perl is using uniq as the sort subroutine.
    This is probably a bug of some sort; I would say that at least my second
    test ought to produce the expected results.

    Ben

    --
    'Deserve [death]? I daresay he did. Many live that deserve death. And some die
    that deserve life. Can you give it to them? Then do not be too eager to deal
    out death in judgement. For even the very wise cannot see all ends.'
    Ben Morrow, Jun 2, 2004
    #6
  7. In article <-guy.com>, Kevin Collins wrote:
    > Hi,
    >
    > I've just stumbled across a strange problem on my HP-UX systems. The
    > following code will demonstrate the problem:
    >
    > #!/usr/bin/perl -w
    >
    > use strict;
    > use warnings;
    >
    > my @list = qw(cc aa bb aa dd zz ee);
    > print join(" ", sort(UniqArray(@list))) . "\n";
    > print join(" ", sort(&UniqArray(@list))) . "\n";
    >
    > sub UniqArray
    > {
    > # This function takes an array reference and returns
    > # an array without dups
    >
    > # local variables
    > my %tmp;
    > my @returns;
    >
    > foreach (@list)
    > {
    > # if the hash element has a value, then don't
    > # add it to return list since we've already added it
    > push (@returns, $_) unless ($tmp{$_});
    > $tmp{$_}++;
    > }
    >
    > return @returns;
    > }


    The code above was not quite correct (I inadvertantly included a different
    version of the code). It should be:

    #!/usr/bin/perl

    use strict;
    use warnings;

    my @list = qw(cc aa bb aa dd zz ee);
    print join(" ", sort(UniqArray(@list))) . "\n";
    print join(" ", sort(&UniqArray(@list))) . "\n";

    sub UniqArray
    {
    # This function takes an array and returns
    # an array without dups

    # local variables
    my %tmp;
    my @returns;

    foreach (@_)
    {
    # if the hash element has a value, then don't
    # add it to return list since we've already added it
    push (@returns, $_) unless ($tmp{$_});
    $tmp{$_}++;
    }

    return @returns;
    }
    Kevin Collins, Jun 2, 2004
    #7
  8. Kevin Collins

    Anno Siegel Guest

    Kevin Collins <> wrote in comp.lang.perl.misc:
    > Hi,
    >
    > I've just stumbled across a strange problem on my HP-UX systems. The
    > following code will demonstrate the problem:
    >
    > #!/usr/bin/perl -w
    >
    > use strict;
    > use warnings;
    >
    > my @list = qw(cc aa bb aa dd zz ee);
    > print join(" ", sort(UniqArray(@list))) . "\n";
    > print join(" ", sort(&UniqArray(@list))) . "\n";
    >
    > sub UniqArray


    [definition snipped]

    > I have two different "home built" versions of Perl (5.6.1 and 5.8.0) and two
    > HP-supplied versions (5.6.1 and 5.8.0).
    >
    > The output I would expect:
    >
    > aa bb cc dd ee zz
    > aa bb cc dd ee zz
    >
    > However, here is what I see:
    >
    > Custom 5.6.1:
    >
    > ee zz dd aa bb aa cc
    > aa bb cc dd ee zz


    [more similar results]

    Perl's "sort" is a peculiar beast in that its (optional) first argument
    can be the name of a subroutine. The name is given as a bareword, and
    so

    sort(UniqArray(@list))

    is ambiguous syntax. It can be parsed as intended, or as a sort where
    UniqArray is used as the comparison routine. The parentheses around
    @list in the second reading are redundant, but possible.

    "&UniqArray" apparently forces the intended interpretation, but both
    are possible. Why different builds of Perl differ in their
    interpretation is another question.

    I snipped the code in UniqArray because it has nothing to do with the
    issue, but actually it would deserve comment also.

    Anno
    Anno Siegel, Jun 2, 2004
    #8
  9. In article <>, Tad McClellan wrote:
    > Kevin Collins <> wrote:
    >
    >> print join(" ", sort(UniqArray(@list))) . "\n";

    > ^^^^^
    >
    > That might as well not be there, UniqArray() never examines its arguments.
    >
    >
    >> sub UniqArray
    >> {

    >
    >> foreach (@list)

    >
    >
    > You should not communicate with subroutines via global variables,
    > you should pass arguments instead.


    Yes, I know - see my follow-up post where I included the "correct" code...

    Kevin
    Kevin Collins, Jun 2, 2004
    #9
  10. Kevin Collins

    Anno Siegel Guest

    David K. Wall <> wrote in comp.lang.perl.misc:
    > Gunnar Hjalmarsson <> wrote:
    >
    > > Kevin Collins wrote:

    >
    > >> sub UniqArray
    > >> {
    > >> # This function takes an array reference

    > >
    > > No, it doesn't. It takes the array @list, which is a package
    > > lexical.


    Lexical variables are independent of any package, the term "package
    lexical" makes no sense. @list is a a file-global lexical array.

    [correct explanation snipped]

    Anno
    Anno Siegel, Jun 2, 2004
    #10
  11. In article <c9l5u9$sqg$>, Ben Morrow wrote:
    >
    > Quoth Kevin Collins <>:
    >> Hi,
    >>
    >> I've just stumbled across a strange problem on my HP-UX systems. The
    >> following code will demonstrate the problem:
    >>
    >> #!/usr/bin/perl -w
    >>
    >> use strict;
    >> use warnings;
    >>
    >> my @list = qw(cc aa bb aa dd zz ee);
    >> print join(" ", sort(UniqArray(@list))) . "\n";
    >> print join(" ", sort(&UniqArray(@list))) . "\n";
    >>
    >> sub UniqArray
    >> {
    >> # This function takes an array reference and returns
    >> # an array without dups
    >>
    >> # local variables
    >> my %tmp;
    >> my @returns;
    >>
    >> foreach (@list)

    >
    > Well, there's a bug here. You are accessing the global @list directly;
    > what you mean is
    >
    > for (@_) {


    Yeah, I've reposted with the correct code.

    >
    > This makes no difference though...
    >
    >> {
    >> # if the hash element has a value, then don't
    >> # add it to return list since we've already added it
    >> push (@returns, $_) unless ($tmp{$_});
    >> $tmp{$_}++;
    >> }
    >>
    >> return @returns;
    >> }
    >>
    >> I have two different "home built" versions of Perl (5.6.1 and 5.8.0) and two
    >> HP-supplied versions (5.6.1 and 5.8.0).
    >>
    >> The output I would expect:
    >>
    >> aa bb cc dd ee zz
    >> aa bb cc dd ee zz
    >>
    >> However, here is what I see:
    >>
    >> Custom 5.6.1:
    >>
    >> ee zz dd aa bb aa cc
    >> aa bb cc dd ee zz
    >>
    >> Custom 5.8.0:
    >>
    >> ee zz dd aa bb aa cc
    >> aa bb cc dd ee zz
    >>
    >> HP's 5.6.1:
    >>
    >> ee zz dd aa bb aa cc
    >> aa bb cc dd ee zz
    >>
    >> HP's 5.8.0:
    >>
    >> aa bb cc dd ee zz
    >> aa bb cc dd ee zz
    >>
    >> I also checked Perl 5.8.0 on RedHat 9.0 and see my expected results.

    >
    > Using
    >
    > This is perl, v5.8.2 built for i686-linux-thread-multi
    >
    > I get the following results:
    >
    > #!/usr/bin/perl -l
    >
    > my @list = qw/cc aa bb aa dd zz ee/;
    >
    > sub uniq {
    > my (@r, %t);
    >
    > # print "ARGS:", @_;
    >
    > for (@_) {
    > push @r, $_ unless $t{$_};
    > $t{$_}++;
    > }
    >
    > return @r;
    > }
    >
    > print sort uniq @list;
    > print sort uniq(@list);
    > print sort(uniq @list);
    > print sort(uniq(@list));
    > print sort &uniq(@list);
    >
    > __END__
    >
    > ee zz dd aa bb aa cc
    > ee zz dd aa bb aa cc
    > ee zz dd aa bb aa cc
    > aa bb cc dd ee zz
    > aa bb cc dd ee zz
    >


    I've just run your code and this is the output I see:

    ccaabbaaddzzee
    ccaabbaaddzzee
    ccaabbaaddzzee
    ccaabbaaddzzee
    aabbccddeezz

    I'm not clear at all how you are getting the results you've shown...

    > Uncommenting the 'print "ARGS:"' line makes it clear what is happening:
    > in the first three cases, perl is using uniq as the sort subroutine.
    > This is probably a bug of some sort; I would say that at least my second
    > test ought to produce the expected results.
    >
    > Ben
    >
    Kevin Collins, Jun 2, 2004
    #11
  12. In article <c9l6pn$bo5$-Berlin.DE>, Anno Siegel wrote:
    > Kevin Collins <> wrote in comp.lang.perl.misc:
    >> Hi,
    >>
    >> I've just stumbled across a strange problem on my HP-UX systems. The
    >> following code will demonstrate the problem:
    >>
    >> #!/usr/bin/perl -w
    >>
    >> use strict;
    >> use warnings;
    >>
    >> my @list = qw(cc aa bb aa dd zz ee);
    >> print join(" ", sort(UniqArray(@list))) . "\n";
    >> print join(" ", sort(&UniqArray(@list))) . "\n";
    >>
    >> sub UniqArray

    >
    > [definition snipped]
    >
    >> I have two different "home built" versions of Perl (5.6.1 and 5.8.0) and two
    >> HP-supplied versions (5.6.1 and 5.8.0).
    >>
    >> The output I would expect:
    >>
    >> aa bb cc dd ee zz
    >> aa bb cc dd ee zz
    >>
    >> However, here is what I see:
    >>
    >> Custom 5.6.1:
    >>
    >> ee zz dd aa bb aa cc
    >> aa bb cc dd ee zz

    >
    > [more similar results]
    >
    > Perl's "sort" is a peculiar beast in that its (optional) first argument
    > can be the name of a subroutine. The name is given as a bareword, and
    > so
    >
    > sort(UniqArray(@list))
    >
    > is ambiguous syntax. It can be parsed as intended, or as a sort where
    > UniqArray is used as the comparison routine. The parentheses around
    > @list in the second reading are redundant, but possible.
    >
    > "&UniqArray" apparently forces the intended interpretation, but both
    > are possible. Why different builds of Perl differ in their
    > interpretation is another question.


    That makes sense to me. Honestly, now that I read what you've written and
    look closer at 'perldoc -f sort', I am surprised this hasn't burned me before.

    Its possible that in other cases I am using a Perl builtin function and Perl
    just handles it correctly.

    >
    > I snipped the code in UniqArray because it has nothing to do with the
    > issue, but actually it would deserve comment also.


    Yes - shot myself in the foot by posting the wrong code. I did repost the
    correct code.

    > Anno



    Thanks,

    Kevin
    Kevin Collins, Jun 2, 2004
    #12
  13. Kevin Collins

    Ben Morrow Guest

    Quoth Kevin Collins <>:
    > > Using
    > >
    > > This is perl, v5.8.2 built for i686-linux-thread-multi
    > >
    > > I get the following results:
    > >
    > > #!/usr/bin/perl -l
    > >
    > > my @list = qw/cc aa bb aa dd zz ee/;
    > >
    > > sub uniq {
    > > my (@r, %t);
    > >
    > > # print "ARGS:", @_;
    > >
    > > for (@_) {
    > > push @r, $_ unless $t{$_};
    > > $t{$_}++;
    > > }
    > >
    > > return @r;
    > > }
    > >
    > > print sort uniq @list;
    > > print sort uniq(@list);
    > > print sort(uniq @list);
    > > print sort(uniq(@list));
    > > print sort &uniq(@list);
    > >
    > > __END__
    > >
    > > ee zz dd aa bb aa cc
    > > ee zz dd aa bb aa cc
    > > ee zz dd aa bb aa cc
    > > aa bb cc dd ee zz
    > > aa bb cc dd ee zz
    > >

    >
    > I've just run your code and this is the output I see:
    >
    > ccaabbaaddzzee
    > ccaabbaaddzzee
    > ccaabbaaddzzee
    > ccaabbaaddzzee
    > aabbccddeezz
    >
    > I'm not clear at all how you are getting the results you've shown...


    Well, except for the fact that I missed out the

    $, = ' ';

    line, presumably this is yet another difference between perl versions...
    actually, I'm not quite sure why the list is reversed. 5.8's sort is supposed
    to be stable...

    Ben

    --
    Joy and Woe are woven fine,
    A Clothing for the Soul divine William Blake
    Under every grief and pine 'Auguries of Innocence'
    Runs a joy with silken twine.
    Ben Morrow, Jun 2, 2004
    #13
  14. Kevin Collins

    Paul Lalli Guest

    On Wed, 2 Jun 2004, Ben Morrow wrote:

    > > > my @list = qw/cc aa bb aa dd zz ee/;
    > > >
    > > > sub uniq {
    > > > my (@r, %t);
    > > >
    > > > # print "ARGS:", @_;
    > > >
    > > > for (@_) {
    > > > push @r, $_ unless $t{$_};
    > > > $t{$_}++;
    > > > }
    > > >
    > > > return @r;
    > > > }
    > > >
    > > > print sort uniq @list;
    > > > print sort uniq(@list);
    > > > print sort(uniq @list);
    > > > print sort(uniq(@list));
    > > > print sort &uniq(@list);
    > > >
    > > > __END__
    > > >
    > > > ee zz dd aa bb aa cc
    > > > ee zz dd aa bb aa cc
    > > > ee zz dd aa bb aa cc
    > > > aa bb cc dd ee zz
    > > > aa bb cc dd ee zz


    > actually, I'm not quite sure why the list is reversed. 5.8's sort is supposed
    > to be stable...


    The sort subroutine is returning the array @r. Because %t is a lexical,
    it will be empty each time the sort subroutine is called. Therefore, the
    size of @r each time the routine is called will be either 1 or 2 (it will
    be 1 only in the case where two identical elements are being compared).
    Both of these values are positive, which is the means of telling sort to
    put $b before $a. Assuming sort only compares two elements in the
    original order (that is, $a is always listed before $b in the original
    list), it is easy to see why the results would come back in the reverse
    order.

    Paul Lalli
    Paul Lalli, Jun 2, 2004
    #14
  15. Anno Siegel wrote:
    >> Gunnar Hjalmarsson <> wrote:
    >>> Kevin Collins wrote:
    >>>>
    >>>> sub UniqArray
    >>>> {
    >>>> # This function takes an array reference
    >>>
    >>> No, it doesn't. It takes the array @list, which is a package
    >>> lexical.

    >
    > Lexical variables are independent of any package, the term "package
    > lexical" makes no sense. @list is a a file-global lexical array.


    Thanks for the correction. But I had to test:

    use strict;
    use warnings;

    package A;
    my $lexical = 'apple';
    our $global = 'orange';

    package B;
    #my $lexical = 'banana';
    print '$lexical = ', $lexical, "\n";
    print '$global = ', ($global or '(empty)'), "\n";

    I couldn't do "my $lexical" once again without a warning, but I
    noticed something else that surprised me. The above code outputs:
    $lexical = apple
    $global = orange

    while I had expected:
    $lexical = apple
    $global = (empty)

    When Perl doesn't find a global variable in the current package, does
    it look for a varable with the same name in other packages?

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
    Gunnar Hjalmarsson, Jun 2, 2004
    #15
  16. Kevin Collins

    Ben Morrow Guest

    Quoth Gunnar Hjalmarsson <>:
    > use strict;
    > use warnings;
    >
    > package A;
    > my $lexical = 'apple';
    > our $global = 'orange';
    >
    > package B;
    > #my $lexical = 'banana';
    > print '$lexical = ', $lexical, "\n";
    > print '$global = ', ($global or '(empty)'), "\n";
    >
    > I couldn't do "my $lexical" once again without a warning, but I
    > noticed something else that surprised me. The above code outputs:
    > $lexical = apple
    > $global = orange
    >
    > while I had expected:
    > $lexical = apple
    > $global = (empty)
    >
    > When Perl doesn't find a global variable in the current package, does
    > it look for a varable with the same name in other packages?


    Nope. our declares a lexical name in the current scope which is bound to
    the global variable of the same name in the current package. If you
    change your 'our' to 'use vars', it'll do what you expect (or rather,
    give a strict error).

    Ben

    --
    "If a book is worth reading when you are six, *
    it is worth reading when you are sixty." - C.S.Lewis
    Ben Morrow, Jun 2, 2004
    #16
  17. Ben Morrow wrote:
    > Quoth Gunnar Hjalmarsson <>:
    >> When Perl doesn't find a global variable in the current package,
    >> does it look for a varable with the same name in other packages?

    >
    > Nope. our declares a lexical name in the current scope which is
    > bound to the global variable of the same name in the current
    > package. If you change your 'our' to 'use vars', it'll do what you
    > expect (or rather, give a strict error).


    Hmm.. So that's the difference between "use vars" and "our"... Since
    I still care about 5.005 compatibility, I haven't really begun to use
    "our". Sometimes I wonder if I ever will master even the basics of
    Perl. :(

    Anyway, thanks Ben and Anno for the lesson!

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
    Gunnar Hjalmarsson, Jun 2, 2004
    #17
    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. Mark
    Replies:
    4
    Views:
    2,939
    scoude
    Jan 12, 2011
  2. Steven Van den Berghe

    unexpected map behaviour

    Steven Van den Berghe, Aug 28, 2003, in forum: C++
    Replies:
    2
    Views:
    405
    Christian Jan├čen
    Aug 28, 2003
  3. Old Wolf
    Replies:
    1
    Views:
    379
    Victor Bazarov
    Feb 4, 2004
  4. Replies:
    0
    Views:
    100
  5. king
    Replies:
    5
    Views:
    178
Loading...

Share This Page