Re: RFC: Date::Iterator

2003-12-20 Thread Dave Rolsky
On Fri, 19 Dec 2003 [EMAIL PROTECTED] wrote:

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

What about the DateTime::Set docs do you think needs improvement?


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/


RFI: Module for Creating Navigation Bars

2003-12-20 Thread Shlomi Fish

Hi!

I'm looking for a good module to create HTML navigation bars. Some of the
requirements are:

1. Support for nested navigation bars (with 's and 's).

2. Support for CSS classes, title="" attributes, etc.

3. Support for hiding nested navigation bars or items in specific URLs.

4. Generating relative URLs.

5. Support for sites that are spread across multiple places possibly in
different hosts.

6. Support for external URL's.

Nice to haves would be:

1. Support for Images as links.

2. Support for JavaScript attributes or arbitrary HTML attributes.

Regards,

Shlomi Fish

--
Shlomi Fish[EMAIL PROTECTED]
Home Page: http://t2.technion.ac.il/~shlomif/

An apple a day will keep a doctor away. Two apples a day will keep two
doctors away.

Falk Fish


Re: RFC: Date::Iterator

2003-12-20 Thread Smylers
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