in reply to Re: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution
in thread Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution
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.
|
|---|
| 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 sleet (Pilgrim) on Nov 05, 2024 at 01:26 UTC | |
by marto (Cardinal) on Nov 05, 2024 at 07:49 UTC | |
by stevieb (Canon) on Nov 05, 2024 at 07:59 UTC | |
by stevieb (Canon) on Nov 05, 2024 at 07:42 UTC |