Re^3: Does the experimental builtin::stringify() do anything that scalar() doesn't ?

Why is that useful ?

Data serialization. A string may serialize differently than an integer:

{
    "foo":1,
    "bar":"2",
}
[download]

In the case of that little JSON blurb, a well behaved JSON emitter would take {foo => 1, bar => "2"} and emit JSON with two key/value pairs, one of which has an integer value, and the other of which has a string that contains the character '2'

Why that matters is the subject of many hard to find little bugs

Dave

Comment on Re^3: Does the experimental builtin::stringify() do anything that scalar() doesn't ? Select or Download Code

Replies are listed 'Best First'.
Re^4: Does the experimental builtin::stringify() do anything that scalar() doesn't ? by NERDVANA (Priest) on Apr 12, 2024 at 07:34 UTC
A best-behaved JSON emitter would require you to denote which elements are intended to be numbers, the same way it uses an object to let you denote which elements should be booleans. This would be in keeping with the design of perl, that a scalar should never have an implied type, and use typed operators to coerce the data as it gets used. It's only due to history and implementation details that our JSON modules have tried to be overly clever about detecting which scalars are meant to be numbers, and given us this headache.	[reply]
Re^5: Does the experimental builtin::stringify() do anything that scalar() doesn't ? by choroba (Cardinal) on Apr 12, 2024 at 07:54 UTC
> A best-behaved JSON emitter would require you to denote which elements are intended to be numbers The best-so-far JSON emitter makes it possible, but not required: Cpanel::JSON::XS::Type. `map{substr$_->[0],$_->[1]\|\|0,1}[\\|\|{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^ARGV,3]`	[reply] [d/l]