Re^2: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution

This approach fails for your given example input of 3.14159:

use strict;
use warnings;

use Test::More tests => 1;

my $val = 3.14159;
my $oldval = $val;

my $newval = do {
    use B;
    if ( not B::SVf_POK & B::svref_2object( \$val )->FLAGS or
         -1 != index $val, 'e' ) {
        $val = sprintf '%.4f', $val;
        $val =~ s/\.?0+$//
    }
    "$val"
};

is "$oldval", "$newval";
[download]

I think you have to either "round to an arbitrarily sane length" as your code does or else just go with the flow.

🦛

Comment on Re^2: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution Download Code

Replies are listed 'Best First'.
Re^3: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution by Anonymous Monk on Oct 30, 2024 at 12:06 UTC
Sorry, I wasn't clear. "Numeric" values are result of parsing, but are kept internally as strings (directly from capture buffers), and are treated as numbers only if user performs any calculation. No encapsulation is enforced by `CAM::PDF`, and some of these values can be replaced/assigned (or new ones created) by user, either as, hopefully, actual numbers, but also perhaps they can arrive as "numeric" strings. The idea was for original values to be "passed through" unmodified when writing new file or stringifying content. Ugly strings such as "3.141592653589793" if supplied by user will sneak into output, but I guess let it be, it's syntactically OK. Too much hassle otherwise, to really keep track of what has come from parsing source, and what was added by user.	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution
by Anonymous Monk on Oct 30, 2024 at 12:06 UTC

Sorry, I wasn't clear. "Numeric" values are result of parsing, but are kept internally as strings (directly from capture buffers), and are treated as numbers only if user performs any calculation. No encapsulation is enforced by CAM::PDF, and some of these values can be replaced/assigned (or new ones created) by user, either as, hopefully, actual numbers, but also perhaps they can arrive as "numeric" strings. The idea was for original values to be "passed through" unmodified when writing new file or stringifying content. Ugly strings such as "3.141592653589793" if supplied by user will sneak into output, but I guess let it be, it's syntactically OK. Too much hassle otherwise, to really keep track of what has come from parsing source, and what was added by user.

[reply]
[d/l]