Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:42914 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 18604 invoked from network); 4 Feb 2009 14:27:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Feb 2009 14:27:46 -0000 Authentication-Results: pb1.pair.com smtp.mail=rrichards@ctindustries.net; spf=softfail; sender-id=softfail Authentication-Results: pb1.pair.com header.from=rrichards@ctindustries.net; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain ctindustries.net does not designate 207.58.142.213 as permitted sender) X-PHP-List-Original-Sender: rrichards@ctindustries.net X-Host-Fingerprint: 207.58.142.213 smtp2go.com Linux 2.6 Received: from [207.58.142.213] ([207.58.142.213:50801] helo=www.smtp2go.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F8/AA-61634-1E5A9894 for ; Wed, 04 Feb 2009 09:27:46 -0500 Received: from [67.158.171.203] (helo=rrichardsmbp.local) by www.smtp2go.com with esmtp (Exim 4.63) (envelope-from ) id 1LUij5-0003qR-61; Wed, 04 Feb 2009 14:27:39 +0000 Message-ID: <4989A5D6.5010201@ctindustries.net> Date: Wed, 04 Feb 2009 09:27:34 -0500 User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Sebastian Bergmann CC: internals@lists.php.net References: <5EC76153-898F-49C2-BDF1-C227578DB874@pooteeweet.org> <298CA3D0-60B7-4CFD-A2D3-E39D52ECDD46@bitextender.com> <49898DBE.7050200@php.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP2Go-MailScanner-Information: Please contact support@smtp2go.com for more information X-SMTP2Go-MailScanner: Found to be clean X-SMTP2Go-MailScanner-From: rrichards@ctindustries.net Subject: Re: [PHP-DEV] towards the next 5.3 release From: rrichards@ctindustries.net (Rob Richards) Sebastian Bergmann wrote: > Rob Richards wrote: > >> The addition in 5.2.6 was a BC break and is fixed in 5.2.9 >> > > Removing the type-hint is only a short-term fix, IMHO. A better solution > would be to introduce a marker interface that is implemented by the > respective classes of the XML extensions involved and use said > interface in the type hint. > > If that's the route this is going to go, I'd rather be able to set an anytype hint where the developer could possibly restrict this further with a more specific type if they extend the class. Rob