On Fri, 10 Jan 2003, dLux wrote: > I disagree with this, because handling these things are not > object-dependent, but context-dependent. I need to write a function, > which handles dates in one way, but I don't want to force users of the > module work dates like this. > > When I have a function, which prints to a web page, then I localize the > $Class::Date::DATE_FORMAT, and it is used in "print" statements. It is > not an object-attribute, because it belongs to the > execution-context.
But plenty of other things may be per-object, like how to handle overflow in date math. And having it be per-object works just fine for your example as well, whereas a global does not work very well. Basically, class/date attributes are flexible, globals are not. Case closed. > > - exportable "datetime", "localdatetime", "gmdatetime" functions for > > short-cuts of the constructors. > > I like the way Time::Piece overrides localtime and gmtime. I don't see a > need for a whole mess of exported functions, though, and I'm inclined to > export nothing by default. > > I afraid of this thing, because it can mess up with other parts of the > code, but anyway in the newer versions it should be okay. Like I said, I actually lean towards exporting _nothing_. But I think I'd prefer to offer overrides of localtime and gmtime, rather than functions that are confusingly similar, like localdatetime. > > - Object for an invalid date > > Can you explain why this is useful? > > When a date is invalid, then the program does not croak if it is > referenced, and we can pass error-information in it. I won't tell it is > a perfect solution, better way of handling invalid dates are welcome. Can't this be done like this: my $new = $date1 + $date2; die "Invalid date math" unless defined $new; What does having an invalid date object gain me over the above code? -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
