Front page | perl.perl5.porters |
Postings from January 2011
On Thu, Jan 27, 2011 at 02:38:56PM +0000, Ed Avis wrote:
> Leon Timmermans <fawaka <at> gmail.com> writes:
>
> >[cases where evaluating ($b + 0) changes the value of a later expression]
>
> >I think the real bug here is not that a scalar value can have both a
> >numeric and a string value, but that some operators and keywords are
> >polymorphic on the representation of the value.
>
> Well, perhaps. But practically, I do not suggest changing either of
> those things. It is not a problem that a scalar can have both a
> numeric and a string value. What is wrong is that the scalar can
> somehow be altered just by using it in an expression, without
> assigning to it or using any other explicit mutation operator. Its
> values, whatever they may be, should stay the same when you just read
> it.
>
> >From a practical point of view, changing all the operators which
> depend on the representation of a value might be a big task, but
> changing ($b + 0) so that it just looks at the value of $b, but
> doesn't alter it, seems like a smaller fix.
The problem with ($b + 0) is that it *cannot* just look at the value of
$b, if all that $b contains is a string. While you can in Perl, you cannot
add strings and integers in the underlaying machinery. And you aren't
seriously suggesting that:
$b = "foo";
$a = $b + 0;
say $a;
should print "foo", are you?
Now, whether or not the numified value should be cached, and if it's being
cached, whether it should be done as it's now, is a different question.
But people have been coping with this for the past couple of decades.
I don't think anyone is willing to design and implement a change like
this.
Abigail
Thread Previous
|
Thread Next