Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65110 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 73198 invoked from network); 23 Jan 2013 11:36:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jan 2013 11:36:01 -0000 Authentication-Results: pb1.pair.com header.from=tyra3l@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=tyra3l@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.177 as permitted sender) X-PHP-List-Original-Sender: tyra3l@gmail.com X-Host-Fingerprint: 209.85.223.177 mail-ie0-f177.google.com Received: from [209.85.223.177] ([209.85.223.177:34965] helo=mail-ie0-f177.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6B/90-01592-02BCFF05 for ; Wed, 23 Jan 2013 06:36:00 -0500 Received: by mail-ie0-f177.google.com with SMTP id k13so12970851iea.8 for ; Wed, 23 Jan 2013 03:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=84eqz5lCFHbUqGaCe7fM9Y0rWEu4GGW/Fq3IlEfK/wg=; b=FwSThEwE4DFyt74qwkCT5sarSVrTebzomnZ8wCnMtXoGl5q0AVvUIvL3WD3wgBep8E +eFRDck/AXBJk58gP19mFCDZkGXxDiQdgjx/sPiatbasWOAmkTY+CIEiHNZxfApFDVN2 JRvRR5j6yZtTbb2eQNlyMA8IM5s0n4mSO/Fk93NW6qBItDPHcSpCk+4M2YdRQ/vS9Qpl tyRZk3kMnTWDMa1ao0Uy02D14YaS8cvW2dGhiTDXaZ3+StuqtCVT5kaVT+yYpnupoRvl ft9rHrhN08mpc8aY3oDbB48yVzxVSJfgd97qjYzKGbqHI1QSZWj7oSFbYFPozdaGeKug ltGw== MIME-Version: 1.0 X-Received: by 10.50.185.196 with SMTP id fe4mr832240igc.17.1358940957292; Wed, 23 Jan 2013 03:35:57 -0800 (PST) Received: by 10.50.106.138 with HTTP; Wed, 23 Jan 2013 03:35:57 -0800 (PST) In-Reply-To: References: <50F840F4.7080704@zerocue.com> <50FE7579.1010409@zerocue.com> <50FECA4E.6080408@lerdorf.com> Date: Wed, 23 Jan 2013 12:35:57 +0100 Message-ID: To: Benjamin Eberlei Cc: Rasmus Lerdorf , Clint Priest , PHP Developers Mailing List Content-Type: multipart/alternative; boundary=14dae934066507b85304d3f31957 Subject: Re: [PHP-DEV] [VOTE] Property Accessors for 5.5 From: tyra3l@gmail.com (Ferenc Kovacs) --14dae934066507b85304d3f31957 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 23, 2013 at 12:11 PM, Benjamin Eberlei wro= te: > On Tue, Jan 22, 2013 at 6:20 PM, Rasmus Lerdorf > wrote: > > > On 01/22/2013 03:18 AM, Clint Priest wrote: > > > > > > On 1/17/2013 12:20 PM, Clint Priest wrote: > > >> I'm happy to say that Property Accessors is ready for a vote for > > >> inclusion in 5.5 release. > > >> > > >> Nikita and I (as well as Stas a bit) have all been working hard to > > >> make this happen for 5.5, voting and the specifications are here: > > >> > > >> https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting > > >> > > > > > > For those that have voted against this proposal, are there any > > > clarifications that can be made or questions answered? > > > > > > There seems to be a lot of userland support for this proposal from > > > people who don't have voting rights. > > > > The simple explanation from me is that the ROI isn't there on this one. > > It adds a lot of code complexity for very little return. Yes, it saves = a > > couple of lines of boilerplate code for a few people, but the cost is > > high in terms of ongoing maintenance and potential issues for opcode > > caches as well. If you look at the split in voting you will notice it i= s > > pretty much split along the lines of the people who have to maintain > > this code vs. the people who would like a shiny new feature. > > > > I think it would be important to gather the reasons for the No Votes and > ways how to address this problems. > Some from the previous discusisons are: > > * Neglected APC support > * adding complexity to PHP Core > * Reference Handling > * Visibility Rules > * Fear of testing in production > > And come up with solutions to those (like cutting some features, or putti= ng > the code into 5.6 to allow for more testing) > > Since several contributors helped with the development and committed > themselves for quite some time already, then if there were a chance to > address all the concerns then this feature could still move forward (mayb= e > at a later point)? > > Hi, for the record I'm one of the people who thinks that this is a good idea and the implementation improved a bunch from the previous versions/proposals, but I think that there were too many changes which could have introduced new bugs (both in design and implementation). Accepting this feature just before the feature freeze would either prolong the 5.5 release or we could end up in the same spot as with 5.4, where major problems with the new features were discovered after the release plus some of the must-have extensions wasn't ready to work with the new version. I don't wanna hijack the discussion, but I think there are a couple of concerns raised here would worth a separate discussion and possibly changes in our rfc and release process. --=20 Ferenc Kov=C3=A1cs @Tyr43l - http://tyrael.hu --14dae934066507b85304d3f31957--