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]> >
