I see this is a long discussion and it now encompasses Perl's merits.
I would like to add my 2 cents:
"constant" provides barewords, which are a no-no in Perl Best
Practices. It allows it because it bypasses the strict manually to
allow it - on purpose - but it's still bad. If I was reviewing code
and I suddenly saw "return VAR" I would be a little dumbfounded.
Perhaps the person didn't use strict, perhaps it's some esoteric
module, whatever. Besides, I wouldn't know what type it is. That's
another reason why we have types in Perl.
I use Readonly, and I suggest to do the same. Recently Eric fixed the
Readonly::XS bug (on Perl 5.10.0 I think), and it's working smooth.
Sample:
use Readonly;
use Data::Dumper;
our @list = qw{one two three};
Readonly my $var => {
key => "value",
map( { ( $_ => 16 ) } @list ),
key2 => "value2",
};
print Dumper(\$var);
On Thu, Mar 5, 2009 at 9:35 AM, Gaal Yahas <[email protected]> wrote:
>
> "our" affects package globals, but its effect on their names is
> certainly lexical. If you do:
>
> BEGIN { our $foo = 42 }
> print $foo;
>
> That won't compile under strict vars.
>
> Any of these will work though:
>
> package Moo;
> BEGIN { our $foo = 42 }
>
> print $Moo::foo;
>
> {
> our $foo;
> print $foo;
> }
>
> {
> our $foo; # must happen before package switch to catch $Moo::foo.
> package NotMoo;
> print $foo;
> }
>
> On Thu, Mar 5, 2009 at 2:22 AM, Adriano Ferreira <[email protected]>
> wrote:
> > On Wed, Mar 4, 2009 at 9:16 PM, Adriano Ferreira <[email protected]>
> > wrote:
> >> On Wed, Mar 4, 2009 at 8:59 PM, Gaal Yahas <[email protected]> wrote:
> >>> Minor correction: "our" is lexically scoped, so you need:
> >>
> >> No, it is not.
> >>
> >> $ perl -le ' our $foo = 3; { our $foo = 4; } print $foo '
> >> 4
> >>
> >> "our" is package scoped. If you refer to the same package/our variable
> >> name, it is the same variable.
> >
> > Also contrast this to:
> >
> > perl -le 'my $foo = 3; { my $foo = 4; } print $foo '
> > 3
> >
> > I understand that my explanation was a bit misleading because for a
> > similar block with "my" that could not be translated with repeated
> > "my" statements.
> >
> > my $foo = 0;
> > BEGIN { my $foo = 3; } # this $foo is another variable which does not
> > mess with the first one
> >
> > BEGIN { $foo = 1 } # this is an assignment to the first one
> >
> > which when executed leads to the amazing result:
> >
> > $ perl -le 'my $foo = 0; BEGIN { my $foo = 3 } BEGIN { $foo = 1 } print
> > $foo'
> > 0
> >
> > because assigning 1 to $foo at compile-time (by BEGIN) gets wiped at
> > runtime by the simple assignment.
> >
> >
> >
> >
> >>> our @list;
> >>>
> >>> BEGIN {
> >>> �...@list = qw(one two three);
> >>> }
> >>>
> >>> use constant .......;
> >>>
> >>> On Thu, Mar 5, 2009 at 12:07 AM, Shmuel Fomberg <[email protected]>
> >>> wrote:
> >>>> Hi All.
> >>>>
> >>>> Today I've seen a weird behavior in a program. I had something like:
> >>>>
> >>>> our @list = qw{one two three};
> >>>>
> >>>> use constant VAR => {
> >>>> key => "value",
> >>>> map( { ( $_ => 16 ) } @list ),
> >>>> key2 => "value2",
> >>>> };
> >>>>
> >>>> To my surprise, VAR contained only key and key2.
> >>>> I theorized that it is because "use constant" is set in compile time,
> >>>> and @list is empty in that time. @list is populated in run-time, but
> >>>> that is too late for VAR.
> >>>>
> >>>> Am I right or is there other reason for this?
> >>>>
> >>>> Tested on Perl 5.6.
> >>>>
> >>>> Shmuel.
> >>>> _______________________________________________
> >>>> Perl mailing list
> >>>> [email protected]
> >>>> http://perl.org.il/mailman/listinfo/perl
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Gaal Yahas <[email protected]>
> >>> http://gaal.livejournal.com/
> >>> _______________________________________________
> >>> Perl mailing list
> >>> [email protected]
> >>> http://perl.org.il/mailman/listinfo/perl
> >>>
> >>
> > _______________________________________________
> > Perl mailing list
> > [email protected]
> > http://perl.org.il/mailman/listinfo/perl
> >
>
>
>
> --
> Gaal Yahas <[email protected]>
> http://gaal.livejournal.com/
> _______________________________________________
> Perl mailing list
> [email protected]
> http://perl.org.il/mailman/listinfo/perl
_______________________________________________
Perl mailing list
[email protected]
http://perl.org.il/mailman/listinfo/perl
