Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:42451 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30557 invoked from network); 2 Jan 2009 18:16:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Jan 2009 18:16:47 -0000 Authentication-Results: pb1.pair.com header.from=johannes@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=johannes@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 83.243.58.134 as permitted sender) X-PHP-List-Original-Sender: johannes@php.net X-Host-Fingerprint: 83.243.58.134 mailout2.netbeat.de Linux 2.6 Received: from [83.243.58.134] ([83.243.58.134:48343] helo=mailout2.netbeat.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2B/50-28540-C0A5E594 for ; Fri, 02 Jan 2009 13:16:46 -0500 Received: (qmail 30131 invoked by uid 89); 2 Jan 2009 18:32:39 -0000 Received: from unknown (HELO ?192.168.1.102?) (johannes%schlueters.de@93.104.96.127) by mailout2.netbeat.de with ESMTPA; 2 Jan 2009 18:32:39 -0000 To: Marcus Boerger Cc: David =?ISO-8859-1?Q?Z=FClke?= , PHP Internals In-Reply-To: <868073456.20081231173818@marcus-boerger.de> References: <08AA10DA-2704-415C-8A8C-893C89990DC1@bitextender.com> <868073456.20081231173818@marcus-boerger.de> Content-Type: text/plain Date: Fri, 02 Jan 2009 19:16:32 +0100 Message-ID: <1230920192.6125.141.camel@goldfinger> Mime-Version: 1.0 X-Mailer: Evolution 2.24.2 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Re: [PHP-DEV] __invoke() weirdness From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=) Hi, On Wed, 2008-12-31 at 17:38 +0100, Marcus Boerger wrote: > So far it is. Yet I as much as you do not like the inconsistency. So I > spend a little bit on providing the following patch that should do > what > you were looking for. I thought bout this issue for one day or so, there are three things to consider here: - the language design question - implementation-related things - getting 5.3 out For the first question I have to say that this is a major change to language. Bringing this feature in makes it a mixture of a class-based OO model and JavaScript-like class-less OO model. As I tend to read way more code than I write I, personally, prefer the clearer class based approach. Nonetheless there seems to be large support for this, so let's lake a deeper look: > The disadvantage: Calling properties is case sensitive while calling > methods isn't. But since this has nothign to do with this patch and > the patch only increases consistency I am all for applying it. That's one of the symptoms of the underlying problem we're having: In our object implementation methods and properties are kept completely separated. Using properties now like methods will have side effects, one is described above. I found another one today: p = function() { echo 1; }; } } class B extends A { private function p() { echo 2; } } $a = new A(); $b = new B(); $a->p(); $b->p(); ?> What do you expect? Well, the first call, to $a->p(); works, the second one, to $b->p();, doesn't since where accessing the private method B::p(). $ sapi/cli/php test.php 1 Fatal error: Call to undefined method B::p() in test.php on line 16 Depending on your view on this that result can be correct or wrong, it might even be wrong in different ways, maybe overwriting $a->p with $b->p should be forbidden, maybe it should treat private elements like non-existent ones. The obvious thing is that it feels like the "is-a" relationship isn't enforced anymore. Additionally there are other areas with such conflicts: Reflection (ReflectionMethod doesn't work, ReflectionProperty has no hint it's executable, ...) and other meta-functionality are obvious, others might (and will) be quite hidden. I guess the only solid way to implement that feature would be by merging the property and method tables into an "element" table so we reduce such conflicts -- while that's a major engine and language change. Every other approach will have side-effects. This leads us to the third consideration: 5.3 is around 1.5 years in development now with lots of new features. It was announced that we wanted to go to a beta status to get it out soon ("release early, release often" ...) I'd say it would be good to concentrate on making 5.3 stable and then see how new features are accepted. If users really demand such a functionality, when using closures for "real life" development, we can still add it, but that should be done with the time needed to identify side-effects and other consequences, not in a rush during holiday season after a feature freeze has been announced. johannes