Stas Malyshev <smalys...@sugarcrm.com> wrote:
> > 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.
The above wouldn't quite work as you lose timezone information.
I've thought about this before and we can only do this if we allow to specify
the class name as extra argument.
I'd like to add this, but it is a bit unrelated to this change.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
