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

[Anonymous Monk]

A question about Perl this time. Is following an OK solution (and backward compatible to e.g. 5.010) to write numeric values as they were parsed, be it either 3.14 or 3.14159, i.e. not to force rounding to arbitrarily "sane" length? Results of numeric calculations still have to be formatted. The emergency test for "e" is for values from whatever sources whose past allows Perl to treat them as strings. Scientific notation is syntax error. CAM::PDF does just "$val", I don't think it's good enough.

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"
}

[hippo]

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";

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

[Anonymous Monk]

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.

[Anonymous Monk]

Another question (hopefully they aren't regarded "do the research for me" or "write code for me"). W.r.t. output, is adding a dependency on File::Copy for trivial task a bad idea? Is "append mode" considered undesirable perhaps in file systems I have no experience with?

Originally, a file is always slurped in, content scalar either appended to or re-generated from scratch for incremental or clean save respectively; then output file is opened in create mode and scalar is printed.

In worst case (minute incremental update to a very large file using the same file name), almost exact huge copy is written anew. I don't like this design and re-wrote this part. Incrementally updating to the same file name opens a file in append mode, then as large or small as required data is written. Incrementally updating to a different file name uses File::Copy::copy() before that. Especially useful if original file wasn't slurped-in.

I could do without File::Copy, performing instead read/print loop through some small buffer (16 KB or what's OK value these days), but why shouldn't I use dedicated/optimised module? Only not to add a dependency? On core module?

As to "no appending" in original CAM::PDF, I can envision a case when file is modified by someone between my read and write. Then corrupt PDF would be saved. But it's no worse than my erasing "someone"'s work by opening a file in create mode. Both scenarios are somewhat improbable for PDFs on disk.

[sleet]

is adding a dependency on File::Copy for trivial task a bad idea?

Note that it's included in core:

$ corelist File::Copy

Data for 2024-10-20
File::Copy was first released with perl 5.002

[marto]

It's worth specifying all dependencies. Some systems ship with a bastardised 'perl', excluding things from the core.

[stevieb]

is adding a dependency on File::Copy for trivial task a bad idea?

What sleet is saying here is that it's absolutely not a bad idea to add the dependency to your chain, particularly because it's already in core. Personally, I have quite a few distributions on the CPAN that I wanted to make small, but when it comes to core modules, I'm all in on including them and decreasing my work-load for known-good functionality.