Ok, it's time to have a few conclusions about this discussion. Some of these conclusions are more general than my module and involve the CPAN as a whole.
Some like my module, some don't. Some would like to see it on CPAN, some don't.
About *not putting* it on CPAN, the main reasons are:
* there is already DateTime::Event::Recurrence that does the same job and a lot more with a standardized interface * the presence of many modules that do the same job leads to diluition of efforts and lowers the usefulness of CPAN * DateTime modules are designed to work together, mine isn't designed to work with anything * Date::Iterator is not easier than DateTime::Event::Recurrence and is much less flexible than it
About *putting* it on CPAN:
* Some people liked it * it's simple * it's useful
And, last, there is a proposal to rename it to Date::Calc::Iterator
(did I miss anything?)
Now:
I didn't find DateTime::Event::Recurrence on CPAN when I was looking for a solution for my problem, but I have to say that even if I had a clear and clean explaination like the one that Rick Measham gave on this list, I'd probably coded my module anyway. I have the feeling that the time I spent to write the module (not a lot, indeed: it took more time to document it than to write it) was far less than I had to learn the DateTime thing.
The impression I get from the DateTime::Event::Recurrence is that even if you need to accomplish a simple task, you have to learn a lot about the DateTime framework, which is the exact contrary of the Perl philosophy as a whole: it is stated somewhere (the Camel Book? The Llama book?) that you can learn a few Perl to begin to make something useful with it.
My impression could well be wrong. But, in that case, there is something wrong also in how the DateTime modules are explained and documented.
About CPAN pollution, I feel that pollution as a wealth. The solution to that could be the recently added feature of rating modules, but we should have a "sort by rating" on search.cpan.org to make it more useful. Besides, there are good reasons to require a registration before you can rate a module, but the tradeoff is that not many people are rating modules at this time... The possibility of rating a module should be advertised by the CPAN module itself after a successful installation, IMHO (or does recent versions already do it?).
Diluition of efforts is a real problem in CPAN, but not in this case: since there is DateTime::Event::Recurrence I had nothing to do to add this functionality to the DateTime project, nor I could contribute in any other way.
My module *doesn't* want to be flexible.
About the name thing, I'd call it Date::Calc::Iterator:
* if my module was a subclass (like I did with Net::LDAP::Express) * if the "parent namespace" was needed to clearly illustrate what the module does (like I did with Data::Password::BasicCheck; it's not a subclass of Data::Password, but I felt that it was the right namespace to put a module that does basic password checking; moreover, Data::BasicCheck meant nothing!)
Date::Iterator is not a subclass of Date::Calc: it *uses* it; and Date::Calc as a namespace for my module is just confusing: my modules Iterates over Dates, fullstop. The "Calc" part is confusing.
For the reasons written above, I'd put Date::Iterator on CPAN after stating clearly in the docs that:
* it *depends* on Date::Calc * there is already DateTime::Event::Recurrence that does this sort of things, and can do a lot more
But before doing it I'll wait for more comments about this message. Maybe I am totally wrong, and you have good argumentations that will make me change my mind.
Thank you for the time you spent in this discussion so far
Ciao Marco
