Dave Rolsky wrote:
Except if the code he doesn't control returns a DateTime object that he
wants to pass into other code he controls.
This is why DateTime doesn't do polymorphism right. DateTime gets
subclassed in order to provide other ways of looking at dates,
especially to look at them through different calendars, but the
underlying information represented by a DateTime-or-subclass object
is always the same. So any code that wants to return such information
returns an object of its favourite DateTime class, regardless of which
class is the caller's favourite.
The new operation he wants to perform, checking whether a date is in
the future, is not defining a new kind of date. Subclassing would make
sense if you could categorically ask that question about some dates and
not about others. In reality we don't have such a distinction, except
around the floating pseudo-timezone which is too deeply embedded in the
object model to sort out. Logically this operation is not something that
different dates process differently (polymorphically); it's a single
operation that is performed in a consistent manner using a date object
as pure data. It's logically a function, nothing else.
-zefram
