[Edinburgh-pm] CPAN upload

[Miles Gould]

On Tue, Dec 20, 2011 at 8:49 PM, Murray <perl at minty.org> wrote:
> On Tue, Dec 20, 2011 at 08:31:06PM +0000, Miles Gould wrote:
>> I'm afraid I won't be able to make it to Ed.pm this month, as I'll be
>> down south with the family. However, I should be back in time for
>> Heretics on the 29th.
>
> Sorry, can't help with cpan & can't make thursday ... but heretics is looking
> promising!

It looks like everything went OK, because this is now the first hit
for List::Priority on search.cpan.org:

search.cpan.org/~mgould/List-Priority-0.03rc1/Priority.pm

Accordingly, I've closed the "shift does the same thing as pop!" bug
that led me to fork the module in the first place.

Anyway, now that I've verified that the upload process works, I'd like
to ask for some more help on design. My current roadmap looks like
this:

v0.03

- basically, what's there now: the code now does what the
documentation says it does, which is all that's really required in a
module which has apparently been sitting around largely unloved for
nine years.
- rewrite some of the docs to (a) be less ugly, (b) be more
grammatical, (c) make the useful options{SIZE} feature more apparent.
- MOAR TESTS

v0.04

- replace the current horrible "return an error string when given the
wrong number of arguments" design with calls to croak(). (I'm thinking
an API-breaking change deserves to be separated from a bugfix
release).
- give some guidance in the docs as to what, if any, reason there is
to use this module over the other eleventy bajillion priority queues
on CPAN.

Questions:

1. Does this sound sane?
2. There's the potential for confusion between the recently-added
size() method (number of elements currently in the list) and
options{SIZE} (*maximum* number of elements the list will hold).
Should I rename one? What to?
3. What would you suggest doing in the other cases where functions
return error strings, namely "you tried to add an element to a list
that's already full of higher-priority things" and "you tried to add
something that's already in the list, and we don't support that for
reasons best known to the original author". croak()ing seems excessive
in this situation, but returning error strings doesn't seem very
sensible either.

I'd like to maintain the current low-dependency nature of the module,
if possible.

TIA,
Miles