On Mon, 4 Jul 2005, Sam Vilain wrote:
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
Uh, what system doesn't use the Gregorian calendar? Maybe I'm
misintrepreting the word system, but I certainly don't know of any
non-Gregorian OS's. Non-Gregorian calendars are important for some things
to some people, but the Gregorian calendar is the international standard,
and the _only_ one you could use for things like web calendars, shared
appointment calendars, event calendars, scheduling future events, etc.
Again, what's the Huffman coding here? If it is important to be able to
write the code you have above (which I doubt), then it's _less_ important
than this:
use Date;
my $date = Date.new(:today); # is :today lefit? not sure
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.
While I'd like the above to work (modulo export-by-default) I don't think
it needs to "find" the right calendar. It should just use Gregorian by
default. Those people who need to use another calendar _know_ that they
need to do so, whereas many people probably never think that the calendar
they use all the time is the Gregorian calendar. To them it's just "the
calendar".
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)
DateTime already provides an explicit conversion API that all calendar
need to support via the from_object() method.
In general, I'm not convinced that lots of DWIMmy magic is a good thing in
an extension, at least not in a first pass. If you commit to rewriting
the language, that's a much bigger and harder goal than simply committing
to getting datetime stuff right, which is already incredibly hard.
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.
See above. Ingy's a big fan of rewriting the language and creating new
idioms. I'm not.
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! :)
And if you get it wrong people hate you. Telling people they need to do
this:
use Date qw(:date);
or whatever is not a big deal. If enough people love it, it can be added
as a default later, but generally speaking exporting by default is
obnoxious.
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.
I think you mean "interface" rather than "role", right? Or do you
actually expect to provide implementations that will be imported via a
role? I think spec'ing an interface is a good thing, but the interface
name should be something longer than "Date", which should be reserved for
something more widely used and more frequently typed. That's why I'd
suggest Date::Calendar::Interface or something like that.
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.
Yes, definitely.
- 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.
Well, I'd just call it DateTime, again for the huffman coding. And I'd
call the interface Date::Interface::Time or something like that.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
