Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:31364 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 49628 invoked by uid 1010); 2 Aug 2007 07:15:33 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 49593 invoked from network); 2 Aug 2007 07:15:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Aug 2007 07:15:31 -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.94.239.5 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.94.239.5 jdi.jdi-ict.nl Linux 2.6 Received: from [82.94.239.5] ([82.94.239.5:44990] helo=jdi.jdi-ict.nl) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 70/93-30967-88481B64 for ; Thu, 02 Aug 2007 03:15:22 -0400 Received: from localhost (localhost [127.0.0.1]) by jdi.jdi-ict.nl (8.13.7/8.12.11) with ESMTP id l727FGEM022954; Thu, 2 Aug 2007 09:15:17 +0200 Date: Thu, 2 Aug 2007 09:15:16 +0200 (CEST) X-X-Sender: derick@kossu.ez.no To: Andi Gutmans cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= , Etienne Kneuss , internals@lists.php.net, Ilia Alshanetsky In-Reply-To: <698DE66518E7CA45812BD18E807866CE7C10BB@us-ex1.zend.net> Message-ID: References: <46AE49B3.2070100@php.net> <1185883035.23889.31.camel@johannes.nop> <698DE66518E7CA45812BD18E807866CE7C10BB@us-ex1.zend.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Subject: RE: [PHP-DEV] Fix inconsistencies in OO calls From: derick@php.net (Derick Rethans) On Wed, 1 Aug 2007, Andi Gutmans wrote: > This is not really a fix. When we worked on PHP 5 we deliberately > decided to relax on all the weird dynamic constructs which didn't > provide a lot of value for the majority of use-cases. Of course the > Reflection API was going to be the way to do these dynamic things in > future. It would also simplify the engine's code. The reason why those > first constructs work were for BC reasons. We didn't want to break > existing code but wanted to not add on top of this. > > While it may feel inconsistent I still prefer the existing path. Maybe > for PHP 6 we can even make an E_STRICT message for the old way which > refers you to the Reflection API? I think that'd be a bad idea. I don't see a problem with this patch at all, and why should people use reflection here? As you're always so much for BC, I find it strange that you're suggesting to remove something totally harmless and instead want people to force to use the slow Reflection API which is meant for introspection... Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org