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.
Re: RFC: Date::Iterator
On Friday, December 19, 2003, at 12:19 PM, Marco Marongiu wrote: Could I contribute to the DateTime project? I think I can't. Working with calendars and times would require me an effort bigger than I can take. A contribution you could make fairly easily is a documentation patch, showing how it could be used for the specific case you needed in your work. Proliferation of modules on CPAN is evil? Maybe. Maybe not. It could create confusion, you are right. But... well, I'll say in italian: Cio` che hai in piu` non ti impoverisce; I don't have a good translation in english, but it could sound like things you got and don't need don't make you poor. It's a natural selection process: people search for modules that do the job, read the docs and make a choice. If my module is bad, they simply won't use it. Yeah, but it still stays on CPAN to confuse the next person. Natural selection isn't quite the right metaphor here, since modules don't die out from disuse. -Ken
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]
Re: RFC: Date::Iterator
James E Keenan writes: On Fri, 19 Dec 2003 12:13:56 +0100, Marco Marongiu wrote: I created the module in subject for an application I had to create for my job. I am planning to release it on CPAN [snip] SEE ALSO The wonderful Date::Calc module ... wouldn't there be something to be said for placing it in that module's hierarchy? I.e., Date::Calc::Iterator. That sounds like a very good idea. For what it's worth I don't consider Date::Calc to be wonderful -- not because there's anything particularly wrong with it _per se_, but that a couple of years ago I just found trying to deal with dates and times in Perl in general was very painful indeed, mainly because there were so many date- and time-related modules that each performed a task OK but didn't play nicely with each other. Therefore I am immensely grateful to Dave Rolsky and co for bringing DateTime into existence, and doing it so well. I am very happy with the DateTime modules, which seem to do everything that any of the other date or time modules do, but they can actually be used together (as well as getting those tricky issues such as leap seconds and daylight savining correct). So now I use the DateTime modules for all work involving dates or times, even smaller jobs where they are arguably overkill, because it's so nice to have standard classes that can be used everywhere, and I can't imagine ever wanting to use any of the other Date modules. But I understand Simon's point about it being nice to have nice simple modules for simple tasks. _Personally_ I'd prefer that even simple modules using dates or times used DateTime objects, but just as I've got a fondness for DateTime it's obvious that others have warm feelings for Date::Calc. In my day job, I too have encountered situations where I want to write functions that require Date::Calc and extend its functionality, and I began to map out a plan to a series of modules which would be little add-ons for that module. It appears to me that Date::Iterator takes a similar approach. I suspect that if you look at DateTime and friends you'll find it does everything you want. But if you have a reason for wanting a suite of Date::Calc-compatible modules then naming them Date::Calc::Foo sounds like an excellent idea. In fact, if your module _had_ been named Date::Calc::Iterator from the outset, it would, IMHO, have been less vulnerable to the criticism that it was polluting CPAN because there's something else up there with the same or similar functionality. That's quite possibly true! Let the DateTime folks continue their excellent work in the DateTime:: namespace, and let Date::Calc fans work independently in the Date::Calc:: namespace, nobody's interfering with anybody else and the names make it blindingly obvious which cabal each module belongs to. Smylers
RFC: Date::Iterator
Ciao a tutti I created the module in subject for an application I had to create for my job. I am planning to release it on CPAN I already started to get some reviews from italian perl mongers, I would also like to have yours. Below you have the man page I wrote so far. You can also download the module for testing it from http://bugs.unica.it:/modules/ Cheers --bronto NAME Date::Iterator - Iterate over a range of dates SYNOPSIS use Date::Iterator; # This puts all the dates from Dec 1, 2003 to Dec 10, 2003 in @dates # @dates will contain ([2003,12,1],[2003,12,2] ... [2003,12,10]) ; my $i1 = Date::Iterator-new(from = [2003,12,1], to = [2003,12,10]) ; my @dates1 ; push @dates,$_ while $_ = $i1-next ; # Adding an integer step will iterate with the specified step # @dates will contain ([2003,12,1],[2003,12,3] ... ) ; my $i2 = Date::Iterator-new(from = [2003,12,1], to = [2003,12,10], step = 2) ; my @dates2 ; push @dates,$_ while $_ = $i2-next ; ABSTRACT Date::Iterator objects are used to iterate over a range of dates, day by day or with a specified step. The method next() will return each time an array containing ($year,$month,$date) for the next date, or undef when finished. DESCRIPTION new Creates a new object. You must pass it the end points of a date interval as hash references: $i = Date::Iterator-new( from = [2003,12,1], to = [2003,12,10] ) from and to are, obviously, required. Optionally, you can specify a custom step with the step key, for example: $i = Date::Iterator-new( from = [2003,12,1], to = [2003,12,31], step = 7 ) ; will iterate on December 2003, week by week, starting from December 1st. next Returns the next date; in list context it returns an array containing year, month and day in this order, or undef if iteration is over; in scalar context, it returns a reference to that array, or undef if iteration is over. HISTORY 0.01Original version; created by h2xs 1.22 with options -CAX -b 5.6.0 --use-new-tests --skip-exporter -O -v 0.01 Date::Iterator SEE ALSO The wonderful Date::Calc module AUTHOR Marco Marongiu, [EMAIL PROTECTED] COPYRIGHT AND LICENSE Copyright 2003 by Marco Marongiu This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
Re: RFC: Date::Iterator
Andy Wardley wrote: Marco Marongiu wrote: NAME Date::Iterator - Iterate over a range of dates Nice! Thanks Andy! $i = Date::Iterator-new( from = [2003,12,1], to = [2003,12,10] ) As a matter of convenience, can I suggest that in addition to list references you also allow dates to be specified as strings? $i = Date::Iterator-new( from = '2003/12/1', to = '2003/12/10' ) Something like this should do the trick: $date = ref $date eq 'ARRAY' ? $date : [ split(/\D+/, $date) ]; If you split on any non-digit characters then it allows for different formats like '2003/12/1', '2003-12-1', '2003 12 1' and so on. Yup! Really nice idea! I'll go for it!!! Thanks a lot --bronto -- Marco MarongiuEmail: [EMAIL PROTECTED] System Administrator Phone: +39 070 460 1684 Tiscali S.p.A.Fax: +39 070 460 9684 International IT Services
Re: RFC: Date::Iterator
On Fri, 19 Dec 2003, Marco Marongiu wrote: Date::Iterator - Iterate over a range of dates I like it! # This puts all the dates from Dec 1, 2003 to Dec 10, 2003 in @dates # @dates will contain ([2003,12,1],[2003,12,2] ... [2003,12,10]) ; my $i1 = Date::Iterator-new(from = [2003,12,1], to = [2003,12,10]) ; my @dates1 ; push @dates,$_ while $_ = $i1-next ; I recently needed to handle the same thing, but also needed to be able to handle hourly steps. Would it be possible to add support for something like the following: my $i1 = Date::Iterator-new(from = [2003,12,1,10], to = [2003,12,10,23] ); and have it return arrays (or refs) with [,mm,dd,hh] back? This could also be expanded in both directions, to handle: my $i1 = Date::Iterator-new(from = [2003,12], to = [2004,3] ); and: my $i1 = Date::Iterator-new(from = [2003,12,1,10,6], to = [2003,12,2,3,55] ); The latter to be a range of minutes from 2003-12-01 10:06 to 2003-12-02 3:55. I realize that probably wasn't your origonal intention at all, but that would be really handy. BTW - I'd be happy to contribute to Date::Iterator to add support for the above type of scenarios if you'd like. -- Josh I.
Re: RFC: Date::Iterator
Andy Wardley [EMAIL PROTECTED] wrote Something like this should do the trick: $date = ref $date eq 'ARRAY' ? $date : [ split(/\D+/, $date) ]; Never use the value of ref() except in a true/false test. The correct way to tell if something is an array ref is ref $date UNIVERSAL::isa($date, 'ARRAY') Mike Guy
Re: RFC: Date::Iterator
[EMAIL PROTECTED] wrote: On Fri, 19 Dec 2003, Marco Marongiu wrote: Date::Iterator - Iterate over a range of dates I like it! Thanks Josh! I recently needed to handle the same thing, but also needed to be able to handle hourly steps. Would it be possible to add support for something like the following: my $i1 = Date::Iterator-new(from = [2003,12,1,10], to = [2003,12,10,23] ); and have it return arrays (or refs) with [,mm,dd,hh] back? This could also be expanded in both directions, to handle: my $i1 = Date::Iterator-new(from = [2003,12], to = [2004,3] ); and: my $i1 = Date::Iterator-new(from = [2003,12,1,10,6], to = [2003,12,2,3,55] ); The latter to be a range of minutes from 2003-12-01 10:06 to 2003-12-02 3:55. I realize that probably wasn't your origonal intention at all, but that would be really handy. BTW - I'd be happy to contribute to Date::Iterator to add support for the above type of scenarios if you'd like. Yes, please, do it :-) You are right, your modification goes far beyond the scope of my work, but I'd be really happy to see that someone takes my code as a base to go one step further. Could we discuss in private on the release plan? Thank you! Ciao --bronto -- Marco MarongiuEmail: [EMAIL PROTECTED] System Administrator Phone: +39 070 460 1684 Tiscali S.p.A.Fax: +39 070 460 9684 International IT Services
Re: RFC: Date::Iterator
Mark Stosberg wrote: Dosn't DateTime::Set and DateTime::SpanSet already address this problem-space, but in a more flexible way? http://search.cpan.org/~fglock/DateTime-Set-0.14/lib/DateTime/Set.pm It allows span sets to be non-contiguous, such a set of meetings occurring every Wednesday. It also returns DateTime objects, giving you all the flexibility of formatting and features that a such an object implies. I'd be interesting in hearing a bit more about cases where this new module would be a better choice. I took a look at the page you mentioned. My module does just one, very specific thing. DateTime::Set is flexible, powerful... but when you just need to iterate over a range of days with a constant step, it looks overkill to me. DateTime::Set covers about all cases one could need to handle. Mine covers just one case. Ciao --bronto -- Marco MarongiuEmail: [EMAIL PROTECTED] System Administrator Phone: +39 070 460 1684 Tiscali S.p.A.Fax: +39 070 460 9684 International IT Services
Re: RFC: Date::Iterator
On Fri, Dec 19, 2003 at 03:44:51PM +0100, Marco Marongiu wrote: Mark Stosberg wrote: Dosn't DateTime::Set and DateTime::SpanSet already address this problem-space, but in a more flexible way? http://search.cpan.org/~fglock/DateTime-Set-0.14/lib/DateTime/Set.pm It allows span sets to be non-contiguous, such a set of meetings occurring every Wednesday. It also returns DateTime objects, giving you all the flexibility of formatting and features that a such an object implies. I'd be interesting in hearing a bit more about cases where this new module would be a better choice. I took a look at the page you mentioned. My module does just one, very specific thing. DateTime::Set is flexible, powerful... but when you just need to iterate over a range of days with a constant step, it looks overkill to me. DateTime::Set covers about all cases one could need to handle. Thanks for the response. I can appreciate the distinction. Sometimes big and powerful is a better approach, sometimes simplicity is better. You might add a mention of this module to your SEE ALSO section if you haven't already, though. Mark -- http://mark.stosberg.com/
Re: RFC: Date::Iterator
Mark Stosberg wrote: Thanks for the response. I can appreciate the distinction. Sometimes big and powerful is a better approach, sometimes simplicity is better. :-) You might add a mention of this module to your SEE ALSO section if you haven't already, though. Good point :-) Is on my notepad now! Thank you Ciao --bronto -- Marco MarongiuEmail: [EMAIL PROTECTED] System Administrator Phone: +39 070 460 1684 Tiscali S.p.A.Fax: +39 070 460 9684 International IT Services
Re: RFC: Date::Iterator
On Fri, 19 Dec 2003, Marco Marongiu wrote:
My module does just one, very specific thing. DateTime::Set is flexible,
powerful... but when you just need to iterate over a range of days with
a constant step, it looks overkill to me.
Really? But with DateTime::Event::Recurrence you very easily generate
these types of sets. For example, for a set of dates one per day:
use DateTime;
use DateTime::Event::Recurrence;
my $start = DateTime-new( year = 2003, month = 10, day = 3 );
my $end = DateTime-new( year = 2003, month = 11, day = 10 );
my $daily = DateTime::Event::Recurrence-daily( start = $start, end = $end );
while ( my $dt = $daily-next ) { ... }
How hard is that?
What does your module offer that makes it worth _not_ getting all the
other features DateTime.pm offers, like useful time zone support, lots
of formatting parsing options, the ability to do set math on sets
(union, difference, intersection, etc.)?
The API is maybe _slightly_ simpler, but not by very much at all.
However, I think the docs for DT::Event::Recurrence need some work,
because I don't the fact that you can do easy stuff with it is obvious.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: RFC: Date::Iterator
Dave Rolsky wrote:
Really? But with DateTime::Event::Recurrence you very easily generate
these types of sets. For example, for a set of dates one per day:
use DateTime;
use DateTime::Event::Recurrence;
my $start = DateTime-new( year = 2003, month = 10, day = 3 );
my $end = DateTime-new( year = 2003, month = 11, day = 10 );
my $daily = DateTime::Event::Recurrence-daily( start = $start, end = $end );
while ( my $dt = $daily-next ) { ... }
How hard is that?
my $i = Date::Iterator-new( from = [2003,10,3], to = [2003,11,10] ) ;
while (my $day = $i-next) { ... }
Is this harder?
What does your module offer that makes it worth _not_ getting all the
other features DateTime.pm offers, like useful time zone support, lots
of formatting parsing options, the ability to do set math on sets
(union, difference, intersection, etc.)?
Maybe the fact that I don't need all the other features?
However, I think the docs for DT::Event::Recurrence need some work,
because I don't the fact that you can do easy stuff with it is obvious.
--
Is there a think missing?
Anyway, I agree with you: from the docs you have the feeling that all
the framework is a lot complicated...
Ciao
--bronto
--
Marco MarongiuEmail: [EMAIL PROTECTED]
System Administrator Phone: +39 070 460 1684
Tiscali S.p.A.Fax: +39 070 460 9684
International IT Services
Re: RFC: Date::Iterator
Michel Rodriguez wrote: Polluting CPAN with modules that duplicate existing functionalities is definitely NOT responsible behaviour, especially in areas like Date:: and Time:: where there is already much confusion, and an coordinated effort to fix that confusion through DateTime:: In your case why not see if you can write a patch to one of the DateTime modules that would give you an interface similar to what you wrote? Dear Michel First of all, thanks for your advice. As I said in my first mail, Date::Iterator came out to solve a problem I had at work. And as it happened to you, I decide to write a new module after a lot of searching into cpan. DateTime modules didn't come out from those searches, unfortunately. But, as Dave Rolsky recognized, even if I found them the documentation itself doesn't encourage people to use it for simple tasks... Could I contribute to the DateTime project? I think I can't. Working with calendars and times would require me an effort bigger than I can take. If you look at the module code, it am just plain using a single function from a single module (Date::Calc): I have no experience on doing things like that myself. Proliferation of modules on CPAN is evil? Maybe. Maybe not. It could create confusion, you are right. But... well, I'll say in italian: Cio` che hai in piu` non ti impoverisce; I don't have a good translation in english, but it could sound like things you got and don't need don't make you poor. It's a natural selection process: people search for modules that do the job, read the docs and make a choice. If my module is bad, they simply won't use it. Instead of hiding my module in my insignificant website, wouldn't it be better to write on top and bottom of the docs an advice like this is a small module and does a few things; you probabily want to take a look at DateTime and DateTime::Event::Recurrence http://datetime.perl.org? Waiting for a new advice... Ciao and thanks again --bronto -- Marco MarongiuEmail: [EMAIL PROTECTED] System Administrator Phone: +39 070 460 1684 Tiscali S.p.A.Fax: +39 070 460 9684 International IT Services
Re: RFC: Date::Iterator
On Fri, 19 Dec 2003, Marco Marongiu wrote:
Dave Rolsky wrote:
[...]
How hard is that?
my $i = Date::Iterator-new( from = [2003,10,3], to = [2003,11,10] ) ;
while (my $day = $i-next) { ... }
Is this harder?
What does your module offer that makes it worth _not_ getting all the
other features DateTime.pm offers [...]
Maybe the fact that I don't need all the other features?
I believe this kind of attitude leads to dilution of efforts and lowers
the usefulness of CPAN. I know it is hard to decide to abandon a module
that you spent some time writing and whose interface you are (obviously)
quite happy with. But if you really want to do something useful for the
community, it is nevertheless The Right Thing To Do (tm).
I have more than once started writing code, only to discover, after
discussing it here, that I had overlooked an existing module that did
nearly the same thing. In this case I either just abandon the module, or
put it up on my website but not on CPAN. If I think I came up with an
interesting interface that could improve the existing module, then contact
the author to see if they would be willing to accept a patch.
Polluting CPAN with modules that duplicate existing functionalities is
definitely NOT responsible behaviour, especially in areas like Date:: and
Time:: where there is already much confusion, and an coordinated effort
to fix that confusion through DateTime::
In your case why not see if you can write a patch to one of the DateTime
modules that would give you an interface similar to what you wrote?
--
Michel Rodriguez
Perl amp; XML
http://www.xmltwig.com
Re: RFC: Date::Iterator
[EMAIL PROTECTED] (Marco Marongiu) writes:
my $i = Date::Iterator-new( from = [2003,10,3], to = [2003,11,10] ) ;
while (my $day = $i-next) { ... }
Marco, in case you're getting discouraged, I think there's certainly
a place for Date::Iterator; I like it a lot, and I *really* like modules
in the modular tradition that do one thing and one thing well, rather
than modules in the library tradition that do everything to a reasonable
degree.
I haven't looked at the code yet, but I'd still quite like to see it on
CPAN.
--
Wouldn't you love to fill out that report? Company asset #423423
was lost while fighting the forces of evil.
-- Chris Adams in the scary.devil.monastery
Re: RFC: Date::Iterator
* Marco Marongiu [EMAIL PROTECTED] [2003-12-19 19:21]: But... well, I'll say in italian: Cio` che hai in piu` non ti impoverisce; I don't have a good translation in english, but it could sound like things you got and don't need don't make you poor. And that is exactly the reason why I agree with Dave here. It has more features than I need is never a good reason not to use something. It makes getting my task done more complex than it has to be - that would be a good reason. But it isn't the case here. I discovered time and again that the most popular modules on CPAN are useful and popular exactly because they can do MUCH more than anyone needs, but are still easy to use for simple tasks. -- Regards, Aristotle If you can't laugh at yourself, you don't take life seriously enough.
Re: RFC: Date::Iterator
[EMAIL PROTECTED] (Dave Rolsky) writes: No, but it's not easier, and it's _much_ less flexible. The difference between you and I is that you see that as a bad thing and I see it as a good thing. It's a philosophical difference when it comes down to it, such as between Windows programming and Unix programming, or more like GNU Unix and BSD Unix. I don't want to make a fuss, but if I did, I'd start talking about the cat(1) Reference Manual. ;) Really, there's room for both kinds of module on CPAN, and there's room for more than one philosophical viewpoint on CPAN too. Didn't someone famous say something about there being more than one way to do it? -- The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: RFC: Date::Iterator
On Fri, 19 Dec 2003, Marco Marongiu wrote:
As I said in my first mail, Date::Iterator came out to solve a problem I
had at work. And as it happened to you, I decide to write a new module
after a lot of searching into cpan. DateTime modules didn't come out
from those searches, unfortunately. But, as Dave Rolsky recognized, even
if I found them the documentation itself doesn't encourage people to use
it for simple tasks...
Could I contribute to the DateTime project? I think I can't. Working
with calendars and times would require me an effort bigger than I can
take. If you look at the module code, it am just plain using a single
function from a single module (Date::Calc): I have no experience on
doing things like that myself.
Proliferation of modules on CPAN is evil? Maybe. Maybe not. It could
create confusion, you are right. But... well, I'll say in italian: Cio`
che hai in piu` non ti impoverisce; I don't have a good translation in
english, but it could sound like things you got and don't need don't
make you poor. It's a natural selection process: people search for
modules that do the job, read the docs and make a choice. If my module
is bad, they simply won't use it.
Instead of hiding my module in my insignificant website, wouldn't it be
better to write on top and bottom of the docs an advice like this is a
small module and does a few things; you probabily want to take a look at
DateTime and DateTime::Event::Recurrence http://datetime.perl.org?
OK, that will teach me not to get suckered ino this kind of discussion
;--(
I think your module could be rewritten as syntaxic sugar over the existing
DateTime::* ones (or merged as a patch into an existing one).
It brings 2 things: a compact way to create a date for a day, and a
compact syntax to create an ierator over days. What integrating it into
the DateTime hierarchy would do is to allow it to play nice with the other
modules.
I haven't kept all the mails in the thread so I can't look at your
original code, but I believe the following would work in a similar way. I
would move the simpledate2datetime method somewhere else though, as it is
somewhat orthogonal (do I get points for using this first in this thread?)
to the iteration feature.
Does this make sense?
#!/usr/bin/perl -w
use strict;
# use as a list
my @days = DateTime::Iterator-new( from = 2001-11-03, to = 2001-11-10);
foreach my $day (@days ) { print $day-ymd . \n; }
# use as an iterator
my $days= DateTime::Iterator-new( from = [ 2001, 11, 03], to = [ 2001, 11, 10]);
while( my $day= $days-next) { print $day-ymd . \n; }
package DateTime::Iterator;
use Carp;
use DateTime;
use DateTime::Event::Recurrence;
sub new
{ my( $class, %options)= @_;
carp need a to and from option to daily_sequence
unless( defined( $options{from}) defined( $options{to}));
my $from = simpledate2datetime( $options{from});
my $to = simpledate2datetime( $options{to});
my $daily_set = DateTime::Event::Recurrence-daily;
return wantarray ? $daily_set-as_list( start = $from, end = $to )
: $daily_set-iterator( start = $from, end = $to )
;
}
sub simpledate2datetime
{ my $simpledate= shift;
unless( UNIVERSAL::isa( $simpledate, 'ARRAY'))
{ $simpledate= [split /-/, $simpledate ] }
my %date_args;
@date_args{qw( year month day)}= @$simpledate;
return DateTime-new( %date_args);
}
--
Michel Rodriguez
Perl amp; XML
http://www.xmltwig.com
Re: RFC: Date::Iterator
On Fri, 19 Dec 2003, Dave Rolsky wrote:
On Fri, 19 Dec 2003, Simon Cozens wrote:
[EMAIL PROTECTED] (Marco Marongiu) writes:
my $i = Date::Iterator-new( from = [2003,10,3], to = [2003,11,10] ) ;
while (my $day = $i-next) { ... }
Marco, in case you're getting discouraged, I think there's certainly
a place for Date::Iterator; I like it a lot, and I *really* like modules
in the modular tradition that do one thing and one thing well, rather
than modules in the library tradition that do everything to a reasonable
degree.
I agree, that's why the DateTime project is made up of many different
modules, each of which addresses a specific area.
But the difference between the DateTime modules and Marco's module is that
the DateTime modules are specifically designed to work _together_. The
biggest problem with the date time code on CPAN outside the DateTime
space is that while there are many problems solved, everybody has a
slightly different API, so it's hard to chain a set of modules together to
solve bigger problems.
With the DateTime modules, you can pick and choose the pieces you need,
and still be sure that in the future, if you need to do more, you can
easily integrate other DateTime modules into your code. I think that's
far more modular than anything else out there.
At the begining of this thread, I through Date::Iterator sounded great. My
opinion on whether or not it should go into CPAN has gone back and forth.
I happened to need something just like that, except I needed it to handle
hour's as well. I offered to help add that to Date::Iterator.
DateTime::Event::Recurrence was mentioned, so I thought I'd check it out
(it's documentation doesn't make it seem nearly as easy as it should
seem).It's easy enough to use, and works well as expected. There's a
downside though... I had to install 13 other modules!
Date::Iterator would only (I think) require Date::Calc.
If all you need to do is Iterate over dates, Date::Iterator seems like a
much better choice to me. Overhead is important in many situations.
It would also be good for one off solutions.
So I don't know. DateTime::Set and DateTime::Event::Recurrance could both
use much better documentation, but I still see a place for Date::Iterator.
For now, I'll be using DateTime::Event::Recurrance, because I need to deal
with time based date sequences, and because I got in all installed.
--
Josh I.
Re: RFC: Date::Iterator
On Fri, 19 Dec 2003 12:13:56 +0100, Marco Marongiu wrote: Ciao a tutti I created the module in subject for an application I had to create for my job. I am planning to release it on CPAN [snip] SEE ALSO The wonderful Date::Calc module Your README makes clear that Date::Iterator depends on Date::Calc, which is a non-standard module. I believe that should be stated more explicitly in the POD. And given that it _does_ depend on Date::Calc, wouldn't there be something to be said for placing it in that module's hierarchy? I.e., Date::Calc::Iterator. (Preferably after consulting with Date::Calc's author first, of course.) In my day job, I too have encountered situations where I want to write functions that require Date::Calc and extend its functionality, and I began to map out a plan to a series of modules which would be little add-ons for that module. It appears to me that Date::Iterator takes a similar approach. In fact, if your module _had_ been named Date::Calc::Iterator from the outset, it would, IMHO, have been less vulnerable to the criticism that it was polluting CPAN because there's something else up there with the same or similar functionality. Jim Keenan
