[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl5-porters
Subject:    Re: Scalar "type" flags, public and private (POK/IOK/NOK)
From:       demerphq <demerphq () gmail ! com>
Date:       2015-11-30 17:32:18
Message-ID: CANgJU+X2-xfsWVHpaM=OeUwkwSF4BqXysYKrgw0OWKzy7MJRxg () mail ! gmail ! com
[Download RAW message or body]

On 30 November 2015 at 18:30, demerphq <demerphq@gmail.com> wrote:
> On 30 November 2015 at 17:44, Zefram <zefram@fysh.org> wrote:
>> demerphq wrote:
>>>                                                     There basically
>>>is no way to tell if a SCALAR that is IOK and POK was originally a
>>>string or originally a number.
>>
>> We deliberately do not distinguish those cases, and introducing such
>> a distinction would cause trouble for existing code that justifiably
>> thinks it knows how to convey a scalar value from one place to another.
>
> This feels like a bad choice of words. I don't want to know what the
> original form was, I just dont want perl to lie to me when the
> conversion is lossy.
>
>>
>>>          in some specialized cases, serialization for instance, this
>>>can be a very big deal, possibly resulting in data loss.
>>
>> No, it still doesn't matter what the scalar was originally.  What matters
>> is which fields need to be stored in order to fully represent the
>> scalar value.  The answer to that question may be "IV only", "PV only",
>> "either", or "both".  Serialisers can already determine this and make
>> their representation decisions accordingly.
>
> As I showed, no they can't do so reliably.

At least not without great expense, such as checking if the
stringified version of  the numeric field matches the string value
contained in the SV.

Yves
[prev in list] [next in list] [prev in thread] [next in thread]