On Tue, 2 Mar 2004, Rich Bowen wrote: > But, as I said, I'd like for someone to look at what I've done, and make > sure that I'm within the bounds of what's permitted. Thanks.
So I took a look. I think there's a fundamental problem, which is that you've basically written something that's more of a wrapper around DateTime than a real calendar module. What I'm getting at is that you mostly treat datetimes in Gregorian terms (or use epoch values) in your API, for example the constructor. But for calendar modules, if people want to construct a new date in calendar X from a Gregorian date, they can simply do: my $dt_in_X = DateTime::Calendar::X->from_object( object => DateTime->new( ... ) ); Similarly, if they want the epoch value for a datetime in X, they can do: DateTime->from_object( object => $dt_in_X )->epoch; So I think your module should only provide a "Discordian API". In other words, the constructor should take Discordian parameters (season, day, year), _seperately_, so it's something like this: my $disco = DT::C::Discordian->new( season => 'bureaucracy', year => 3166, day => 47 ); And the only get methods you should offer are those that are needed to retrieve Discordian info. If you want to offer a string based constructor, that should probably be another methods, like: from_string( string => 'bureaucracy 47, 3166' ) though a strptime-ish interface would be much nicer. Also, I don't think inheriting from DateTime.pm is a good thing here, since it just confuses the issue. In 'real life', a discordian date _is not_ a Gregorian date, in the sense of being a "more specific" subtype of Gregorian date. It is just _convertable_ to a Gregorian date. Of course, you're free to use any internal representation you want, so you can store a DateTime object internally. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
