On Sun, 6 May 2001 05:30:08 +0530, Abhijit Menon-Sen said:
> On 2001-05-05 19:06:24, [EMAIL PROTECTED] wrote:
> >
> > I've never encountered a real application where microsecond precision
> > was necessary in a calendaring context. Is this a real concern?
>
> Time representations are important in non-calendaring contexts too. As a
> generalised framework for the CPAN, I'm sure some people who don't care
> about reefknot will want to use it. ;-)
Although some of the reefknot modules may be based on this structure, I'm not
making any effort to do things with reefknot in mind. That is, I want to do
something here that works really well, and if reefknot can benefit from it,
that's fine, but it's a side-effect, and not the primary goal.
> Attosecond precision is meaningless in real applications, but the SS.NN
> syntax doesn't penalise the common case. Anything which doesn't need
> sub-second precision can just ignore it.
OK, that makes sense. So then which date format are you recommending that we
use as the "common language"?
> > > Something which avoided the re-blessing would be less fragile:
> > >
> > > my $disco = Date::Discordian->new(disco => '23 Chaos, YOLD 3177');
> > > my $mdisco = Date::Mayan->new($disco);
> > > print $mdisco->as_string; # or whatever.
> >
> > Not sure what you mean by "less fragile."
>
> $self->{FOO} might mean different things to Date::Foo and Date::Bar, and
> re-blessing references between classes doesn't call the constructor for
> the second class. It's not worth the trouble to try to get everyone to
> use unique keys (or, indeed, a hash-based object representation).
OK, very good point. So if we create a new object in the way that you suggest,
then we only have to require that they supply one common method, called ical
(or, if some other date format seems to be a better base, we'll use that
keyword).
--
Rich Bowen - [EMAIL PROTECTED]
.. and another brother out of his mind, and another brother out at New
York (not the same, though it might appear so)
Somebody's Luggage (Charles Dickens)
