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: Simple multi-level tie
Okay, so I ended up having more time last night than I thought I would.
I finished Tie::Filter and the filter packages for scalars, arrays, and
hashes. I've decided to hold off on writing one for handles as it is a
significantly more complicated problem--and it might be better as an
IO:: class.
Anyway, the dist is named Tie-Filter-1.02 and it's been indexed at
http://search.cpan.org/~hanenkamp/Tie-Filter-1.02/
so feel free to take a look at make suggestions.
Regards,
Sterling
On Wed, 2003-12-17 at 14:00, Andrew Sterling Hanenkamp wrote:
I would like the ability to store a complicated record inside of a DBM
file. I looked in the usual places and perldoc -q DBM gives me:
Either stringify the structure yourself (no fun), or else get
the MLDBM (which uses Data::Dumper) module from CPAN and layer
it on top of either DB_File or GDBM_File.
Therefore, I went in search of a solution to automate the
stringification. I didn't find anything other than MLDBM for doing
something like this and it seems like a little much for my purposes. All
I need is something like this:
$hash{name} = value1:value2:value3:...;
I've done some work with Tie::Memoize and really like it's interface, so
I decided to write something like it for wrapping hashes. Thus,
Tie::HashWrapper was born. It may be used like this:
tie my %wrappee, 'AnyDBM_File', ...;
tie my %wrapper, 'Tie::HashWrapper', \%wrappee,
-deflate_value = sub { join ':', @{$_[0]} },
-inflate_value = sub { split /:/, $_[0] };
$wrapper{name} = [ value1, value2, value3 ];
and so forth. In addition, if one wants to have more complicated keys,
one may add -deflate_key/-inflate_key values to the call to tie. I
haven't uploaded it CPAN yet pending documentation and finding a good
name.
Does Tie::HashWrapper seem reasonable? Or does anyone have a better
name? Have I gone off the deep-end again and rewritten something that
already exists and I missed it?
Cheers,
Sterling
--
Andrew Sterling Hanenkamp
http://Andrew.Sterling.Hanenkamp.com/
[EMAIL PROTECTED] / [EMAIL PROTECTED]
Myth: Linux has a lower TCO
Fact: If you consider that buying NT licenses for business use is
tax-deductible, as are all those tech support calls, NT actually
has a lower TCO than Linux! How are you going to expense software
that doesn't cost anything? Eh?!?
-- From a LinuxToday post
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: Simple multi-level tie
Andrew Sterling Hanenkamp wrote:
use Storable qw(freeze thaw);
use Tie::HashWrapper;
tie my %wrappee, 'AnyDBM_File', ...;
tie my %hash, 'Tie::HashWrapper', \%wrappee,
-inflate_value = sub { thaw(shift) },
-deflate_value = sub { freeze(shift) };
$hash{a}{complicated}[4]{data} = [ 'structure' ];
I quit using DBM files after one corrupted on me during an aborted
write. I suppose I could have simply copied the dbm before and after all
my operations, but
with the advent of transaction-safe DBD::SQLite and the ever-presence of
DBIx::Tree, I feel much more comfortable just tossing my
complicated data in a RDBMS and pulling it out.
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
