Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78298 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78169 invoked from network); 24 Oct 2014 10:20:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Oct 2014 10:20:10 -0000 Authentication-Results: pb1.pair.com smtp.mail=nikita.ppv@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=nikita.ppv@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.46 as permitted sender) X-PHP-List-Original-Sender: nikita.ppv@gmail.com X-Host-Fingerprint: 209.85.215.46 mail-la0-f46.google.com Received: from [209.85.215.46] ([209.85.215.46:33692] helo=mail-la0-f46.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E3/62-62277-9D72A445 for ; Fri, 24 Oct 2014 06:20:10 -0400 Received: by mail-la0-f46.google.com with SMTP id gi9so2368437lab.19 for ; Fri, 24 Oct 2014 03:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VufclUI0TUSVvawjyRazRLuihGKMjf46HaX2FpIj4vc=; b=mWL1QVot5z9rikdGOS8rSHLsS4JACIIG7s/aeKp5jR84w83f8jhc/tbqiAnm7t7Rzy YnoE0XjONAjEZAoj9ZTTBCWWqtZqZwxrj04HjIQIfzoLfAzphfOjVAeJN5puEt8DxINi W3PTt1erWjfZOsBmYUympXYA/tjD8SsS3y+QlDppPACTs3UKHKNqFVfCJkW1I0JIjmiN 86YEiXfcktUISO3bUHDK23fBY+CY7ujybcHSuLOO4/IvtFvtpX21oGwPGe4rDx/lZhG9 aPQBYg4Xz8/O5PgbVexcwGYKxLOg4Vt0Sw5V5SXfL8hFXhghp2b1R/G9q7VZiI2GcCSy zlFQ== MIME-Version: 1.0 X-Received: by 10.152.44.233 with SMTP id h9mr3321509lam.73.1414146006678; Fri, 24 Oct 2014 03:20:06 -0700 (PDT) Received: by 10.25.134.86 with HTTP; Fri, 24 Oct 2014 03:20:06 -0700 (PDT) In-Reply-To: <6E04B9BE-854E-4112-8C74-7D90BD8BFE95@ajf.me> References: <6E04B9BE-854E-4112-8C74-7D90BD8BFE95@ajf.me> Date: Fri, 24 Oct 2014 12:20:06 +0200 Message-ID: To: Andrea Faulds Cc: PHP Internals Content-Type: multipart/alternative; boundary=089e0160b3ba63827105062886e8 Subject: Re: [PHP-DEV] [RFC] Readonly Properties From: nikita.ppv@gmail.com (Nikita Popov) --089e0160b3ba63827105062886e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 24, 2014 at 1:36 AM, Andrea Faulds wrote: > Good evening once again, > > Here=E2=80=99s another RFC: https://wiki.php.net/rfc/readonly_properties > > It proposes, with a working implementation, a modifier for properties tha= t > makes them readable and writeable from different scopes. > > Since I am a big proponent of including specification patches in new RFCs= , > I have decided to put my money (or rather, time) where my mouth is and I > have actually written a specification patch before writing an RFC. I woul= d > love to see this become the new standard for RFCs affecting the language. > > If you are curious at all about the behaviour, I suggest perusing the > fairly comprehensive set of twelve tests included in the main patch to > php-src. > > Thanks! > While I think the functionality behind this proposal is nice in principle, I have two objections with the RFC: 1. It uses the "readonly" modifier, to refer to a property that is publicly readable, but protectedly writable (or protectedly readable and privately writable). This isn't entirely obvious from the term "readonly" and also does not match the behavior of other languages employing a "readonly" modifier, like C#. An additional complication may be encountered in the case where the readonly property stores an object, in which case I presume it will be possible to modify the stored object ($obj->readonlyProp->prop = =3D 42), which is likely not expected "readonly" behavior. 2. If the aim of this RFC is to replace the getFoo() pattern with the use of "readonly public $foo" properties, a primary difference will be that a getFoo() method can be declared in an interface, whereas a "readonly public $foo" property cannot be. Thus code making use of interfaces will not be able to employ this feature. And I don't think that allowing properties in interfaces is reasonable at this point, because the implementations will be limited to simple-storage properties - only with more comprehensive property accessor support would implementations be allowed to use more complex backing code. For these reasons I do not think this RFC is suitable for inclusion in PHP in its current state. As others in this thread have already pointed out, it may be advisable to reconsider readonly properties in the broader context of property accessors. Nikita --089e0160b3ba63827105062886e8--