Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63347 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43202 invoked from network); 11 Oct 2012 12:16:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Oct 2012 12:16:29 -0000 Authentication-Results: pb1.pair.com header.from=sebastian.krebs.berlin@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=krebs.seb@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender) X-PHP-List-Original-Sender: krebs.seb@gmail.com X-Host-Fingerprint: 74.125.83.42 mail-ee0-f42.google.com Received: from [74.125.83.42] ([74.125.83.42:38775] helo=mail-ee0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DB/22-32023-B98B6705 for ; Thu, 11 Oct 2012 08:16:28 -0400 Received: by mail-ee0-f42.google.com with SMTP id l10so1022326eei.29 for ; Thu, 11 Oct 2012 05:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:x-google-sender-delegation:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=PURQrYWXXPXjbpL6wAl1I+yvtdTmrnhAWd+aWHzbhE4=; b=VYDivoJAbVLzmTTAy6n3lqiUj/DAkIYLRqgo+OESjOqn/ydzB51wmhHhaLGc3FP0KT x5CCjqGq3wue/uVBSJWSWjqhgQjoDbNj7QBBSSpAkbj6Ve+9cyh2G7l4en55lvU261oV Vkam98zTCdgs7VArBazcFqj2An/U987YkImxGnEh4ExBLqlXhdTa45nWQlOHBBFb/3tY Gf5Grq19FEbOc5uu7qRlR6M+bzGEc1SJOfzHUdQqgbDD3cheRQ5U+ghJ5gTlU7EEi/Kd FHnFQX6KO60Ru1KqSFvZbTLLH7f08ZZkVAl+GwVjucy0jlNh0NZBtMTpnEl+C1lZSlBD IJfw== MIME-Version: 1.0 Received: by 10.14.209.129 with SMTP id s1mr1152058eeo.24.1349957784851; Thu, 11 Oct 2012 05:16:24 -0700 (PDT) Sender: sebastian.krebs.berlin@gmail.com X-Google-Sender-Delegation: sebastian.krebs.berlin@gmail.com Received: by 10.14.176.73 with HTTP; Thu, 11 Oct 2012 05:16:24 -0700 (PDT) In-Reply-To: <9570D903A3BECE4092E924C2985CE485612B4F63@MBX202.domain.local> References: <9570D903A3BECE4092E924C2985CE485612B3B48@MBX202.domain.local> <5073328D.5000002@gmail.com> <50735165.8010703@aaronholmes.net> <9570D903A3BECE4092E924C2985CE485612B4353@MBX202.domain.local> <760ab4f994a78a846cf86aafda71e0e2@mohiva.com> <9570D903A3BECE4092E924C2985CE485612B4EFE@MBX202.domain.local> <9570D903A3BECE4092E924C2985CE485612B4F63@MBX202.domain.local> Date: Thu, 11 Oct 2012 14:16:24 +0200 X-Google-Sender-Auth: H_XVmQsLbXkDRbZ2T4f2ktrRVao Message-ID: To: internals@lists.php.net Content-Type: multipart/alternative; boundary=047d7b603a783a548604cbc78ac5 Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 From: krebs.seb@gmail.com (Sebastian Krebs) --047d7b603a783a548604cbc78ac5 Content-Type: text/plain; charset=ISO-8859-1 2012/10/11 Clint Priest > Why is everyone so dead set against read-only and write-only? > my opinion 1. public read-only $hours { get { /* .. */ } set { /* .. */ } } And now? That this is even possible is reason enough for me. Especially now the engine must take care about this inconsistency (over the whole inheritance tree). It feels unnecessary. 2. This new keyword is unnecessary 3. Don't know, if it's just my, but I find it slightly annoying, that this discussion even exists. The engine already knows every token, that is required to implement this RFC, so whats this all about? This way it will not be ready for 5.5 and I guess not for 5.6 either... 4. It is more readable, ok, but it is not that much and I think it's just to less to say "Lets rewrite everything and make everything more complex (see 1.) and such!" > > I could not disagree more with you on what is "pretty" and "readable". > > To me: > > public read-only $hours { > get { ... } > } > > Is infinitely more readable and understandable than: > > public $hours { > get() { ... } > private final set($value) { ... } > } > > The latter implies that it can be "set" within the right context > (internally to the class), which is precisely the opposite of what is > desired (read only). > No, it's not the opposite, but only slightly more loosely: It only says "It is 'set'able from within this concrete class, but it is read-only from _everywhere_ else", what is in most cases that, what is _really_ wanted. If you don't want to set it, don't set it. It is your class. And for everyone else, it's really read-only. > > From: Jazzer Dane [mailto:tbprogrammer@gmail.com] > Sent: Wednesday, October 10, 2012 9:18 PM > To: Clint Priest > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Propety Accessors v1.1 > > This all sounds about right. > > In regards to #4 - read-only/write-only: > I think that, from a "pretty syntax" point of view, private final set() {} > and private final get() {} are definitely our best bets. But... from a > logical point of view, I prefer read-only/write-only. > > private final get() {} is technically saying it will always return null. > private final set() {} is technically saying that setting doesn't do > anything - but it still works. > > But I don't see any sane scenario where someone would want to do the > above. Therefore, it may just be best to use them in place of the currently > proposed read-only/write-only. > On Wed, Oct 10, 2012 at 5:35 PM, Clint Priest cpriest@zerocue.com>> wrote: > Okay, I would like this to be the last time there are revisions to this > RFC. > > To sum up the last few days of conversations, I have these down as points > of contention: > > 1. Accessor functions should not be present on the object and callable > directly, for example, $o->__getHours() should not be allowed. > 2. Preferred syntax for accessors should be "public set($value) { ... }" > with no "magic" $value (with possible type hinting) > 3. Automatically implemented get; set; with auto-backing field should be > eliminated as this is not necessary for PHP and is confusing most everyone. > 4. read-only / write-only keywords, keep them or get rid of them? There > is no directly suitable replacement but I believe a private final set() { } > will take care of it, even though it much more verbose. > 5. Error handling for thrown exceptions should be made more appropriate > for accessors > 6. The "truth" of reflection. Should it reveal details internal to how > PHP works on the inside or should it reflect the way PHP presents it as > options? > > Did I miss anything? > > > I will come up with some way for people to vote on the issues at hand and > we can cast our votes and be done with it, then I will finish the project > and get it out the door. > > -Clint > > -- github.com/KingCrunch --047d7b603a783a548604cbc78ac5--