Hi!
> Sebastian had responded off-list that he'd rather have DateTime inherit
> from DateTimeImmutable, instead of the current variant where
> DateTimeImmutable inherits DateTime. While this OO-design principle wise
> makes perfect sense, practically it is not as handy. I've played with a
Actually, I would claim it doesn't make "perfect sense", since it would
mean DateTime would violate DateTimeImmutable's contract of being, well,
immutable. Strictly speaking, they can not either extend from other one,
since they have APIs which are not subset of each other. However, doing
it strictly OO would mean getting into Java-esque web of interfaces,
abstract classes and implementation classes, which would suck.
As for established practice, everybody expects DateTime, so IMHO we
should leave DateTime as base class even though it's not strictly OO-pure.
Speaking of derived classes, though, I wonder how hard it would be to
make DateTime factory methods - such as createFromFormat - to be able to
produce instance of child class? Now if you want to extend DateTime and
use those, you need to implement some weird things like:
$dt = DateTime::createFromFormat($format, $time);
$mydt = new MyDateTime("@".$dt->getTimestamp());
Maybe there's a better way but I'm not sure what it is.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
