Front page | perl.perl5.porters |
Postings from March 2022
On 9/3/22 15:30, demerphq wrote:
>
>> IMO, the problem here is that we are still keeping the old mindset where
>> perls scalars where transformed from one type to the other and we
>> couldn't tell which one was the former one.
>>
>> The thing is that now we know the former type, so, I think we should
>> stop thinking about the-scalar-that-was-created-as-a-number and instead
>> start considering it the-scalar-that-is-a-number.
>>
>>
>> The fact that Perl can internally keep other representations of the
>> scalar (for instance, a string) doesn't change the fact that the scalar
>> *is* a number.
> I think you are missing the point though. "created as a number" and
> "is a number" aren't the same thing.
Yeah, and that is exactly my point, they *can* be the same, it is just a
matter of switching your mental model!!!
Until now, perl was not able to keep scalar types. For instance, after...
$a = 9; say "hello $a";
... $a was both an integer and a string. There was no way to
differentiate between the creation type and the ones acquired along the
scalar life.
But *now*, we can differentiate then, we can decide that $a is a number.
Even if there is a string representation attached to the SV representing
it, we can still consider it is a number.
Because otherwise, what value do we get by thinking that the resulting
$a above, is a number and a string? nothing? just an internal detail?
IMO that is a useless model.
> Perl defines that "7" and 7 are both equivalent in almost every
> regard,
And that doesn't change, different types with transparent conversion
when needed. They keep being equivalent except, as you say, in the
places where they are not:
> the few places they might not be the dev is expected to
> disambiguate, eg logical operators like ^ | & care, nothing else in
> perl does, and in those cases the dev should be specifying which
> behavior they want by doing 0+$x | 0+$y or "$x" | "$y". Because to
> perl both "are" the number seven and both "are" the string "7".
So, what you are saying is that the only safe way to use those operators
is to force an explicit coercion every time they are used?
It is better to have the current semantics which are a minefield?
$a = 7; $b = 8;
say("a: $a, b: $b") if $debug;
$c = $a | $b;
$a = "7a"; $b = "a7";
$a++; $b++;
> But "7" is created as a string, and 7 is created as a number.
>
> We dont want people to think that somehow 7 is less of a number than
> "7" because to Perl they should be the same thing.
Again, that is what you decide your mental model to be. In most cases,
you want 7 and "7" to be equivalent, but not always.
So you can see it as...
1) they are the same except in some cases.
2) they are different things but perl converts transparently between
then as needed.
Now you should consider if (1) is the best and easiest model and the one
you want to promote or if it is just that you like it because you are
used to it.
> However when we interoperate with other systems /they/ make a
> distinction between 7 and "7". And using the wrong one can confuse
> them. So we want a way where serialization layers can know that a
> given $var should be represented as an unquoted number or as a string
> when talking to those external systems. The reason the name is chosen
> to be the cumbersome "created_as_number" is that we don't /want/ code
> to be written that checks these things very often. These functions
> should be extremely rare. That is also why we want to have a
> looks_like_number() as well, because that side-steps the "is a"
> question and changes it to a "can be used as a" question. Its almost
> at the level that if you use one of these functions and you are not
> writing a serialization module then you are basically doing something
> wrong.
>
> Maybe it would even be better to call these functions
> "serialize_as_number" instead of "created_as_number" because that
> would make clear the specialist use case.
It is not just serialization, there are far more use cases where being
able to tell if something is/was-created a number could be useful.
For instance, having a sub that behaves differently when passed a string
or a number (some may find that very unperlish, well, to those I would
say I find very unperlish not letting the programmer decide how to solve
his problem in the best way).
Another common case, very similar to serialization, is interacting with
C or C++ libraries. For instance, one offering some "foo_number" and
"foo_string" functions that you want to wrap as a unique "foo" sub.
Thread Previous
|
Thread Next