Date::Iterator, pollution, rating system, and how to make CPAN a better place [was: Re: RFC: Date::Iterator]
Oh my, oh my... what a mess! :-) 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
Re: Date::Iterator, pollution, rating system, and how to make CPAN a better place [was: Re: RFC: Date::Iterator]
Marco Marongiu wrote: And, last, there is a proposal to rename it to Date::Calc::Iterator 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. Derivation/sub-classing is not the only reason to choose a namespace. Delegation/has-a relationships (for one) are also a good reason, and it sounds like your module fits this case. Namespaces are not about implementation (which is what derivation is doing), theyre about interfaces. And for humans, knowing where to find those modules. Mazda-RX-8 has a Wankel motor in it - does that make it different enough to not be a Car ? Of course not. You drive it just like every other car. Is a minivan a car ? an SUV ? YES. Should they be under CAFE ? (Corporate Average Fuel Economy - Congressional law) *Absolutely* so wrt finding Date::Calc::Iterator, how would one go about it ? search.cpan.org ! and what are your search criteria ? *Date*, *Iterator* I just searched Iterator, and hit several with it as the 3rd level name- *File::Find::Iterator* http://search.cpan.org/author/TEXMEC/File-Find-Iterator-0.3/Iterator.pm *XML::LibXML::Iterator* http://search.cpan.org/author/PHISH/XML-LibXML-Iterator-1.00/lib/XML/LibXML/Iterator.pm *Test::Harness::Iterator* http://search.cpan.org/author/RCAPUTO/POE-0.27/lib/Test/Harness/Iterator.pm So sticking Calc in there's not gonna make it any less 'found', It adds info wrt your dependency, and it keeps Date::* a little less cluttered.
Re: Date::Iterator, pollution, rating system, and how to make CPAN a better place [was: Re: RFC: Date::Iterator]
Jim has said what I was about to (with reference to Namespaces and Subclasses), but let me add my $0.02: The name (space) has nothing to do with implementation technique. It has to do with the problem being solved, or the API. One should not assume that every module in a namespace is a subclass of that namespace. Many infact use aggregation or containment to solve the problem. Date::Calc::Day::Iterator or Date::Calc::DayInterator would be good choices. I think it _is_ useful to get the word 'Day' in there, since someone _could_ come along and choose to implement Date::Calc::Hour::Iterator... (or HourIterator) .. (you would be setting the pattern I would think) etc. If it were just ::Iterator that would be precluded. Lincoln On Tue, 2003-12-23 at 10:34, Jim Cromie wrote: Marco Marongiu wrote: And, last, there is a proposal to rename it to Date::Calc::Iterator 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. Derivation/sub-classing is not the only reason to choose a namespace. Delegation/has-a relationships (for one) are also a good reason, and it sounds like your module fits this case. Namespaces are not about implementation (which is what derivation is doing), theyre about interfaces. And for humans, knowing where to find those modules. Mazda-RX-8 has a Wankel motor in it - does that make it different enough to not be a Car ? Of course not. You drive it just like every other car. Is a minivan a car ? an SUV ? YES. Should they be under CAFE ? (Corporate Average Fuel Economy - Congressional law) *Absolutely* so wrt finding Date::Calc::Iterator, how would one go about it ? search.cpan.org ! and what are your search criteria ? *Date*, *Iterator* I just searched Iterator, and hit several with it as the 3rd level name- *File::Find::Iterator* http://search.cpan.org/author/TEXMEC/File-Find-Iterator-0.3/Iterator.pm *XML::LibXML::Iterator* http://search.cpan.org/author/PHISH/XML-LibXML-Iterator-1.00/lib/XML/LibXML/Iterator.pm *Test::Harness::Iterator* http://search.cpan.org/author/RCAPUTO/POE-0.27/lib/Test/Harness/Iterator.pm So sticking Calc in there's not gonna make it any less 'found', It adds info wrt your dependency, and it keeps Date::* a little less cluttered. -- Lincoln A. Baxter [EMAIL PROTECTED]
Licenses for Perl Distributions As Displayed on search.cpan.org
I recently used the Feedback section on search.cpan.org to ask the following question: I've noticed that the CPAN interface for modules now includes a space for the module's License -- but that few modules have any entry here (e.g., http://search.cpan.org/~jkeenan/List-Compare- 0.22/ http://search.cpan.org/~lds/CGI.pm-3.01/ http://search.cpan.org/~dconway/Parse-RecDescent-1.94/ ). Is this because when we use h2xs to set up the skeleton of a distribution, nothing special is done for License? Or is it because MakeMaker doesn't yet do anything for special for License in the way that it does for, say, YAML? What should I do to get something that will show up in License? Or should I not (yet) bother? Graham Barr picked up my query and was kind of enough to respond quickly, as follows: The license details are taken from the META.yml file. Both MakeMaker, Module::Build and Module::Install can all generate META.yml files. If they all support all fields, I do no know. Graham. Per consultation with people on this list, in my two CPAN distributions I have allowed MakeMaker (v6.16) to automatically generate the META.yml file, and I have not made any edits in that file once generated. The file thus generated contains no License information and, if I understand Graham correctly, that means no License info is going to show up on the search.cpan.org main page for each distribution. Is there anything I could do to generate the License info? Perhaps more to the point, at this point in the development of META.yml, _should_ I do anything about this? (I'm not losing any sleep over this. It's just that I'm always puzzled when I see License: Unknown on my distros' main pages, when I've included the standard language about same terms as Perl itself in the POD.) jimk
Re: Licenses for Perl Distributions As Displayed on search.cpan.org
On 12/23/2003 8:21 PM, James E Keenan wrote: I recently used the Feedback section on search.cpan.org to ask the following question: I've noticed that the CPAN interface for modules now includes a space for the module's License -- but that few modules have any entry here (e.g., http://search.cpan.org/~jkeenan/List-Compare- 0.22/ http://search.cpan.org/~lds/CGI.pm-3.01/ http://search.cpan.org/~dconway/Parse-RecDescent-1.94/ ). Is this because when we use h2xs to set up the skeleton of a distribution, nothing special is done for License? Or is it because MakeMaker doesn't yet do anything for special for License in the way that it does for, say, YAML? What should I do to get something that will show up in License? Or should I not (yet) bother? Graham Barr picked up my query and was kind of enough to respond quickly, as follows: The license details are taken from the META.yml file. Both MakeMaker, Module::Build and Module::Install can all generate META.yml files. If they all support all fields, I do no know. Graham. Per consultation with people on this list, in my two CPAN distributions I have allowed MakeMaker (v6.16) to automatically generate the META.yml file, and I have not made any edits in that file once generated. The file thus generated contains no License information and, if I understand Graham correctly, that means no License info is going to show up on the search.cpan.org main page for each distribution. Is there anything I could do to generate the License info? Perhaps more to the point, at this point in the development of META.yml, _should_ I do anything about this? (I'm not losing any sleep over this. It's just that I'm always puzzled when I see License: Unknown on my distros' main pages, when I've included the standard language about same terms as Perl itself in the POD.) jimk The latest snapshot of MakeMaker does have support for a LICENSE parameter in your Makefile.PL. You could also set the NO_META flag in Makefile.PL and then manually edit the META.yml file (I dislike this option). Or, you can do the Right Think and make the switch to Module::Build :-) Regards, Randy.
Re: Date::Iterator, pollution, rating system, and how to make CPAN a better place [was: Re: RFC: Date::Iterator]
My 2 cents... As far as the namespace for this date iterator... Using Day in it's name is not useful. It's current implementation only speaks days, but that has nothing to do with its possibilities nor potential nor plans (I have no idea what plans there may be). The author could accept or create patches to allow Time or Month or Year or etc based periods. The current module and interface could easily adapt to those changes without consequence to current users. Personally, I'd like to see this module on CPAN (though I've ended up using DateTime::Event::Recurrence). The simplicity in the interface and the requirements to this module go hand in hand with the nature of perl itself. And, as always, TMTOWTDI, and that's not a bad thing. I do think that Date::Calc::Iterator is a good place for it, even though it doesn't inherit from Date::Calc. There are many many places throughout perl books and documentation that state that a module's namespace has absolutely nothing to do with inheriting, nor even dealing with, the base directories module/class. For a very basic example, Date::Calc doesn't inherit from Date.pm. It does seem like a good place to keep it, especially since there is obviously such controversy over the Date:: and DateTime namespaces. Whether it ends up as Date::Calc::Iterator or Date::Iterator, I really hope it does end up on CPAN. Much respect to the DateTime people, but it's a pain to get all the requirements installed. In many instances, this would be much more appropriate. -- Josh I. The basic module would not change. On Tue, 23 Dec 2003, Lincoln A. Baxter wrote: Jim has said what I was about to (with reference to Namespaces and Subclasses), but let me add my $0.02: The name (space) has nothing to do with implementation technique. It has to do with the problem being solved, or the API. One should not assume that every module in a namespace is a subclass of that namespace. Many in fact use aggregation or containment to solve the problem. Date::Calc::Day::Iterator or Date::Calc::DayInterator would be good choices. I think it _is_ useful to get the word 'Day' in there, since someone _could_ come along and choose to implement Date::Calc::Hour::Iterator... (or HourIterator) .. (you would be setting the pattern I would think) etc. If it were just ::Iterator that would be precluded. Lincoln On Tue, 2003-12-23 at 10:34, Jim Cromie wrote: Marco Marongiu wrote: And, last, there is a proposal to rename it to Date::Calc::Iterator 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. Derivation/sub-classing is not the only reason to choose a namespace. Delegation/has-a relationships (for one) are also a good reason, and it sounds like your module fits this case. Namespaces are not about implementation (which is what derivation is doing), theyre about interfaces. And for humans, knowing where to find those modules. Mazda-RX-8 has a Wankel motor in it - does that make it different enough to not be a Car ? Of course not. You drive it just like every other car. Is a minivan a car ? an SUV ? YES. Should they be under CAFE ? (Corporate Average Fuel Economy - Congressional law) *Absolutely* so wrt finding Date::Calc::Iterator, how would one go about it ? search.cpan.org ! and what are your search criteria ? *Date*, *Iterator* I just searched Iterator, and hit several with it as the 3rd level name- *File::Find::Iterator* http://search.cpan.org/author/TEXMEC/File-Find-Iterator-0.3/Iterator.pm *XML::LibXML::Iterator* http://search.cpan.org/author/PHISH/XML-LibXML-Iterator-1.00/lib/XML/LibXML/Iterator.pm *Test::Harness::Iterator* http://search.cpan.org/author/RCAPUTO/POE-0.27/lib/Test/Harness/Iterator.pm So sticking Calc in there's not gonna make it any less 'found', It adds info wrt your dependency, and it keeps Date::* a little less cluttered. -- Lincoln A. Baxter [EMAIL PROTECTED]
