Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78292 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64396 invoked from network); 24 Oct 2014 07:50:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Oct 2014 07:50:28 -0000 Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 192.64.116.216 imap10-3.ox.privateemail.com Received: from [192.64.116.216] ([192.64.116.216:58232] helo=imap10-3.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 54/10-62277-2C40A445 for ; Fri, 24 Oct 2014 03:50:27 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id 383D124010D; Fri, 24 Oct 2014 03:50:24 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at imap10.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap10.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zBT5K7kx21Zo; Fri, 24 Oct 2014 03:50:24 -0400 (EDT) Received: from [137.50.172.154] (oa-edu-172-154.wireless.abdn.ac.uk [137.50.172.154]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id 0510A240120; Fri, 24 Oct 2014 03:50:19 -0400 (EDT) References: <6E04B9BE-854E-4112-8C74-7D90BD8BFE95@ajf.me> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <707B8AA4-6226-4CE3-B764-DDF7B6D18D69@ajf.me> Cc: Kalle Sommer Nielsen , PHP Internals X-Mailer: iPhone Mail (12B411) Date: Fri, 24 Oct 2014 08:50:15 +0100 To: Xinchen Hui Subject: Re: [PHP-DEV] [RFC] Readonly Properties From: ajf@ajf.me (Andrea Faulds) > On 24 Oct 2014, at 06:09, Xinchen Hui wrote: > so you prefer to expose the name of the property anywhere? >=20 > let's say you expose a readonly int value name iSize.. >=20 > but later, the value also need to be a double, >=20 > then you also prefer add another dval? (since you can not simple > change ival name, since it was exposed) Is that not already a problem with functions? You can't change their names. I= f you do change its name, you can add a __get. > I knew this of course, but this is actually not related to this > specific "readonly" RFC >=20 > but if you are strict to this., then I'd like to say, this will > slowdown all FETCH_OBJ_R a bit, since this will need introduce a > condition to check whether a property is readonly.. only faster a > narrow case... Right, it will theoretically make public and protected property lookups ever= -so-slightly slower. I'll need to benchmark it as I doubt it's a big deal in= practice. Though this could be worked around by making the write check be a different f= unction. Or by inlining. -- Andrea Faulds http://ajf.me/=