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

Thanks for posting. You've clearly put some thought into this, which is a really good sign. FWIW, here is my take on your proposal(s).

Even without other considerations, I'd really like to move to "PDF" as root in namespace.

No reason not to, given that the root already exists. If it were me I would not be doing the whole PDF::CAMPDF::* thing but would probably just settle for the shorter PDF::CAM::*. A second "PDF" in there just seems redundant - although others might disagree.

No, I didn't try to ask Chris.

I think it's only polite to ask. Especially if you make it clear that even not replying is perfectly fine. If an objection comes back then you can abide by that but if the reply is "Actually, under CAM::PDF is the perfect home for it" then you're done and dusted.

On the other hand, "Extended" is kind of dull and about nothing.

This is the part where perhaps a positive change might be made. "Extended" hints at some extra functionality but not what that is or how it relates to the parent module. Have you just introduced more subs or have you overwritten existing ones? Is there something which ties all this new code together? Can you sum up in one sentence why any given programmer would use the new module over the existing one (or vice versa)? Perhaps then we can all have a think and come up with something more descriptive (or as you say, at least fun).

🦛

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

Replies are listed 'Best First'.
Re^2: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution by Anonymous Monk on Sep 28, 2024 at 12:45 UTC
Thanks for advice, you are right about being polite, I'll write to Chris shortly. Can you sum up in one sentence... No new functions yet; but smaller final pdf file size because of modern compression; some bugs fixed (no doubt, some added); faster on opening and parsing (and writing), sometimes significantly; somewhat less of a RAM hog. Long version: The `CAM/PDF.pm` contains 133 subroutines; 77 entries are enumerated in API section of the POD (though some of them use wildcards to designate several), and there are 104 methods further described in detail, some marked strictly internal. Plus there are several supporting modules in distribution with quite a few of their own subs. My module, close to 100% complete, has 37 subroutines. Most of them are replacement of originals, either complete re-write or just touched, and some are internal helper subs. No new functions for the end user, actually, at this stage. Added behaviour is triggered using options passed to constructor. Or better let's start with this: I'm planning it to be backward compatible. Whenever someone does: `use CAM::PDF; my $pdf = CAM::PDF->new( $fn_or_stdin_or_pdf, @other_args ); # ... things happen with $pdf` [download] they substitute for my module name and their code works as previously. New features are opt-in, with documented exception. On the external, one such feature is ability to save to 1.5+ version with compressed cross-reference stream and object streams -- thus, smaller file size. No CPAN module can do that, to my knowledge. (Rather, `PDF::API2` can append xref stream on incremental update; but it can only update, not save "cleanly" and optimize; file size can only grow. Plus, it's funny to see a screenful or two of your code in "alien" environment, because the patch was written by yours truly.) Slightly less external option is "no slurping on open", but it only matters for really huge input with high resolution images. Typical office or business pdf file size is dwarfed by what `CAM::PDF` consumes itself. Speaking of which, I changed some of its internal accounting and procedures to improve performance.	[reply] [d/l] [select]
Re^3: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution by Anonymous Monk on Sep 28, 2024 at 17:15 UTC
Since it's mostly internal and no updated interface and you plan to make it backwards compatible (i.e. any changed behavior is opt-in and no change in prereqs) why not ask permission to take over as the maintainer of the original distribution?	[reply]
Re^4: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution by Danny (Chaplain) on Sep 28, 2024 at 17:55 UTC
And possibly changing the name to PDF::CAM and using CAM::PDF as an alias?	[reply]
Re^3: Choosing namespace/name for (my first) CPAN module which is a sub-class of a well-known distribution by sleet (Pilgrim) on Oct 30, 2024 at 11:09 UTC
one such feature is ability to save to 1.5+ version with compressed cross-reference stream and object streams -- thus, smaller file size Hopefully this will be a user configurable option. There are still many systems that only work with the older versions.	[reply]