Re: Date::Iterator, pollution, rating system, and how to make CPAN a better place [was: Re: RFC: Date::Iterator]
Happy new year A. Pagaltzis wrote: If you're gonna go that route and put Day in the name but as a separate namespace level, it should be Date::Calc::Iterator::Day so there isn't a new 3rd level namespace for every date iterator module with only one 4th level name in it. I read all the comments, with this one last. I see your reasons. If Steffen Beyer allows me to do so, I'll call the module Date::Calc::Iterator::Day, implement many of the proposed changes I had here and put it on CPAN. Thanks to everybody for the time you took to discuss this module. Ciao Marco -- Marco MarongiuEmail: [EMAIL PROTECTED] System Administrator Phone: +39 070 460 1684 Tiscali S.p.A.Fax: +39 070 460 9684 International IT Services
Re: Date::Iterator, pollution, rating system, and how to make CPAN a better place [was: Re: RFC: Date::Iterator]
* Lincoln A. Baxter [EMAIL PROTECTED] [2003-12-24 09:39]: 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. If you're gonna go that route and put Day in the name but as a separate namespace level, it should be Date::Calc::Iterator::Day so there isn't a new 3rd level namespace for every date iterator module with only one 4th level name in it. -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
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]
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]