Front page | perl.perl5.porters |
Postings from August 2012
On Tue, Aug 28, 2012 at 06:49:33PM +0100, Dave Mitchell wrote:
> On Tue, Aug 28, 2012 at 11:58:26AM -0400, David Golden wrote:
> > On Tue, Aug 28, 2012 at 9:06 AM, Dave Mitchell <davem@iabyn.com> wrote:
> >
> > >
> > > Depending on how the constant value is is defined, it may be IOK or POK:
> > > by uncommenting the print debug, we change FOO from integer to string.
> >
> >
> > I was thinking more of the truly constant case, where constants are
> > providing more readable test values:
> >
> > use constant OK => 200;
>
> Yeah, but at the time the constant is used, you have no idea of its
> history, or whether its "really" constant.
And, right now, whether something that looks like a string stays as a string,
and something that looks like a number stays as a number. Note that this code
never changes C or $a, yet the behaviour changes as a side effect of the
*read* for the addition:
$ cat constant.pl
use strict;
use warnings;
use constant C => "37";
$a = "155";
sub foo {
print '$a & C is ', $a & C, "\n";
}
for (0, 1) {
foo();
}
$b = $b = C + $$;
foo();
__END__
$ ~/Sandpit/580/bin/perl5.8.0 constant.pl
$a & C is 15
$a & C is 15
$a & C is 1
$ ./perl -Ilib constant.pl
$a & C is 15
$a & C is 15
$a & C is 1
(that's an unthreaded perl. It re-uses the same "37" in all locations. A
threaded perl will behave differently because the constant "37" in the pad is
copied)
I'm not trying to say what is right or what is wrong. I'm saying that
attempting to infer things from flags is generally fraught, because flags
change as a side effect of reads. Even for constants.
Nicholas Clark
Thread Previous
|
Thread Next