Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:42470 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3633 invoked from network); 4 Jan 2009 13:59:36 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jan 2009 13:59:36 -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.133 as permitted sender) X-PHP-List-Original-Sender: johannes@php.net X-Host-Fingerprint: 83.243.58.133 mailout1.netbeat.de Linux 2.6 Received: from [83.243.58.133] ([83.243.58.133:33661] helo=mailout1.netbeat.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 58/44-07052-6C0C0694 for ; Sun, 04 Jan 2009 08:59:36 -0500 Received: (qmail 27230 invoked by uid 89); 4 Jan 2009 14:09:00 -0000 Received: from unknown (HELO ?192.168.1.102?) (johannes%schlueters.de@93.104.112.98) by mailout1.netbeat.de with ESMTPA; 4 Jan 2009 14:09:00 -0000 To: Marcus Boerger Cc: David =?ISO-8859-1?Q?Z=FClke?= , PHP Internals In-Reply-To: <145582992.20090103154744@marcus-boerger.de> References: <08AA10DA-2704-415C-8A8C-893C89990DC1@bitextender.com> <868073456.20081231173818@marcus-boerger.de> <1230920192.6125.141.camel@goldfinger> <145582992.20090103154744@marcus-boerger.de> Content-Type: text/plain Date: Sun, 04 Jan 2009 14:59:31 +0100 Message-ID: <1231077571.6023.28.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 Sat, 2009-01-03 at 15:47 +0100, Marcus Boerger wrote: > > 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. > > Stable also means stable features and semantics. And that includes trying > to get rid of inconsistencies. ... fixing one inconsistency by introducing new inconsistencies? Like that one: foo = "foo"; $o->foo(); // will not work $o->bar = function(){}; $o->bar(); // will work ?> And I fear there will be more. Fixing all of them will take time so we can delay 5.3 for another half year or so (... oh and during that time we find another thing to change which will need proper invastigation, too, so we delay again and then we find ....) -> We should really try to shorten the release cycle, not making it longer. Which, for 5.3, means we should concentrate on fixing bugs, not adding features and change the language. johannes