Dave Rolsky wrote:
I may have been quite vocal in the past about the practical failings
of DateTime for Perl 5, but as I'm sure we both know, the API has needed
Actually, I don't remember you saying anything, but maybe it was a while
back on the datetime list?
Possibly. I have found DateTime unsuitable to quite a few tasks for
various unfortunate reasons; which is a shame given the level of following
and amount of design time that's gone into it.
For instance, the in-memory objects are quite heavy, especially compared to
Class::Date, or a simple ISO representation as used by Date::Manip. I can
see why you'd want to ship a copy of the locale information and timezone
database, but IMHO there needs to be a way that these can be coded to be a
little more space/file efficient. Adding a parser for a new format was easy
enough, but the performance at the end of it was noticably slower than other
modules.
But of course these are all implementation problems so nothing to do with
what I grok DateTime is about ;)
Well, I think what you started already has some serious mistakes. For
one, the Huffman coding is backwards. You've used "Date" for a generic
interface, which is something that only calendar authors need to
implement, and then used Date::Gregorian for the thing that will be used
all the time. Short names like "Date" or "DateTime" should go to the
most commonly used bits, which is the Gregorian implementation.
Interfaces should have long names, like "Date::Calendar::Interface".
That is true, but I think it is also very important that you can use;
if ($item.does(Date)) {
}
And not have to worry about whether you're running on a system that uses
the Gregorian calendar as primary or not. That might seem like an odd
requirement, but I see large sections of the world being forced to use the
relatively useless Solar calendar because of our society's inflexibility,
and it would be nice if we didn't need to force that. Also how are aliens
supposed to write code in Perl 6 if we force them to constantly marshall
their non-linear time bases into our reference frame? We cannot overlook
people living in regions where time requires junctions to be expressed.
In terms of Huffmanisation, I'd also like to see this sort of thing work;
use Date;
my $date = date(time());
And have the Date module find the preferred date module that you want to
use and present that. If your code actually uses Gregorian-style accessors,
then you would want to use Date::Gregorian instead to imply that dependency.
No doubt, there will be a coerce method supplied;
multi sub coerce:<as>( Date $from, Date::Gregorian $to ) { ... }
(something like that - see autrijus' recent journal entry)
So that when you specify that a function requires the Date::Gregorian
interface, or a DateTime interface, or whatever, then it can silently
and transparently cast it.
I also am not big on exporting functions like "date()" by default. I
think that's useful, but it definitely be on request.
I used to be like this, too. Then ingy suggested to me that I add a set()
constructor to Set::Object, exported by default, and I haven't looked back.
Also, I'm not sure how far specced the export traits are, or how far
implemented.
Exporting by default is normally reserved only for the most useful
functions; such as YAML.pm exports Load and Dump but not LoadFile and
DumpFile. If words clash, you can always provide a null export list, but
if you Get It Right™, then the users of the module will just love it! :)
Anyway, I think there's lots of time to play with this. I think you
should feel free to continue working on your code too, since there's no
need to have a unified effort at this time. If you'd prefer to work
together, that's fine too.
Ok, well what I was aiming for was a unified "Date" role - abstract from
the implementation - so that authors of date code can fairly transparently
switch between implementations, if their usage is sufficiently basic.
At the very least, we can probably share parts of each other's test
suites so that both of our implementations are of high quality and we can
learn from each other's experiments.
The really cool thing about developing Perl6 for Pugs at the moment is
that there's no way anyone can use it in production, so we're free to
break backwards compatibility at the drop of a hat ;)
Yes, very true :-).
- Explore a new DateTime API - right now I'm inclined to start with 3
core classes - Date, DateTime, and DateTimeTZ. DateTime would be a
datetime in the floating time zone, while DateTimeTZ would have a real
tz. I'm also thinking of trying to create a Time class, so that
DateTime is simply a container of a Date and a Time. The advantage here
is that authors of calendar modules which have the same 24-hour time
system can reuse that. Probably we'd need Time and TimeLS (leap second)
or something like that.
ok. I think I get what you mean - there's a lot of clock related code that
ends up in the date module. When I next get some Date.pm cycles, I might
have a shot at a "Time" role, too - then perhaps a PointInTime is a Date
and a Time combined.
Sam.
