Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78303 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 88939 invoked from network); 24 Oct 2014 11:54:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Oct 2014 11:54:15 -0000 Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.244 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 198.187.29.244 imap1-3.ox.privateemail.com Received: from [198.187.29.244] ([198.187.29.244:60706] helo=imap1-3.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 23/70-19734-5ED3A445 for ; Fri, 24 Oct 2014 07:54:13 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id 15C51B00094; Fri, 24 Oct 2014 07:54:10 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at imap1.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap1.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id U2u0ICoGFngJ; Fri, 24 Oct 2014 07:54:09 -0400 (EDT) Received: from oa-edu-171-36.wireless.abdn.ac.uk (oa-edu-171-36.wireless.abdn.ac.uk [137.50.171.36]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id D7616B00093; Fri, 24 Oct 2014 07:54:08 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) In-Reply-To: <544A1BF5.3090708@seld.be> Date: Fri, 24 Oct 2014 12:54:06 +0100 Cc: PHP Internals Content-Transfer-Encoding: quoted-printable Message-ID: References: <6E04B9BE-854E-4112-8C74-7D90BD8BFE95@ajf.me> <544A1BF5.3090708@seld.be> To: Jordi Boggiano , Pierre Joye X-Mailer: Apple Mail (2.1990.1) Subject: Re: [PHP-DEV] [RFC] Readonly Properties From: ajf@ajf.me (Andrea Faulds) > On 24 Oct 2014, at 10:29, Jordi Boggiano wrote: >=20 > Thanks for the work (again). It's an interesting small idea but I'd = much prefer revisiting the original getter/setter RFC [1] which had a = majority but just fell short of the 66% mark. >=20 > This RFC only implements parts of the getter/setter functionality = (readonly properties) but it does not address the fact that sometimes = you want to add logic to a setter or a getter and if you don't have = language level getters/setters you end up having to change the interface = of the object from a public property to a getFoo/setFoo pair. >=20 > This leads to everyone having getFoo/setFoo by default just to avoid = interface changes or mixed interfaces of public properties and setFoo. >=20 > On 24 Oct 2014, at 10:34, Pierre Joye wrote: >=20 > As much i really like the idea to have better properties management in > PHP I see this RFC as an attempt to solve only part of the problem > while dropping most of the other ideas implemented in the past RFCs. > My take on that is that some will vote no, or won't like the idea of > adding anything in this area. Making compromises and implement partial > solutions will only delay the implementation of the complete solution. >=20 > Many of us agree that __get/__set is a pain to deal with.The need of > readonly, writeonly or properties with some logic to define or get a > value is a lond due need. Many other languages support that out of the > box since long already. Past RFCs, like the c# one, proposed that. I > would rather focus on trying to find an acceptable syntax and > implementation instead of doing baby steps like that. Baby steps work > very well for scalar type hinting, solving one issue after another, > etc. But for properties we are at the risk of hainvg a serie of > separate RFCs solving the properties management problems in different > ways bringing even more troubles and inconsistencies. I think I might be misunderstood, here. While getters and setters can do = this, and I=E2=80=99m very much in favour of also reviving a simplified = version of the getter/setter RFC (previous one was way too complex), I = don=E2=80=99t see this as partly implementing them/baby steps/etc. I = fact, I think readonly properties could work together with = getters/setters. I don't like using property getters and setters to control whether a = property can be written to or read from. I think they're the wrong = solution for that - why have a virtual property with boilerplate = restricted visibility accessors and mutators that get/set a hidden = private property, with their associated performance penalties, when you = can just make a real property that can't be read by outsiders? I think getters and setters are useful and I probably will try to revive = them too sometime soon, but I think they=E2=80=99re actually the wrong = tool for this specific job. -- Andrea Faulds http://ajf.me/