Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64434 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 266 invoked from network); 26 Dec 2012 09:30:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Dec 2012 09:30:51 -0000 Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.113.146.227 xdebug.org Linux 2.6 Received: from [82.113.146.227] ([82.113.146.227:54635] helo=xdebug.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3A/74-47159-9C3CAD05 for ; Wed, 26 Dec 2012 04:30:50 -0500 Received: from [192.168.0.9] (b0f83a18.bb.sky.com [176.248.58.24]) by xdebug.org (Postfix) with ESMTPSA id A97B7DE13D; Wed, 26 Dec 2012 09:30:45 +0000 (GMT) User-Agent: K-9 Mail for Android In-Reply-To: <50DA40E8.9010702@sugarcrm.com> References: <50C63A7C.8090705@gmail.com> <4DBD0EA5-C45B-4C12-BFE9-E263B255B2C3@strojny.net> <50DA40E8.9010702@sugarcrm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Wed, 26 Dec 2012 09:30:41 +0000 To: Stas Malyshev CC: "internals@lists.php.net" Message-ID: Subject: Re: [PHP-DEV] DateTime improvement From: derick@php.net (Derick Rethans) Stas Malyshev 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