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
