Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56837 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 66098 invoked from network); 7 Dec 2011 18:11:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Dec 2011 18:11:11 -0000 Authentication-Results: pb1.pair.com smtp.mail=will.fitch@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=will.fitch@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender) X-PHP-List-Original-Sender: will.fitch@gmail.com X-Host-Fingerprint: 209.85.216.170 mail-qy0-f170.google.com Received: from [209.85.216.170] ([209.85.216.170:40881] helo=mail-qy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 05/F1-54298-E3CAFDE4 for ; Wed, 07 Dec 2011 13:11:10 -0500 Received: by qcsc21 with SMTP id c21so506297qcs.29 for ; Wed, 07 Dec 2011 10:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=2n6O4ckJKymJ2Sw3KE4/GiwGh4vfGvB9TR8i9JIHUqw=; b=IYRoOhWBJ1U2bv4S9LqnDSAozoV/Isv5qZii/TQ9xZwymbuYAuX1y8n4Vp4uxqE+8+ ClhMIOQJE7TLKlzJNSMjNOJgJ4zXxo0zsNFZ8krTqWJD0XaeaSnLDjX0VVxyob8W4GUr eMAVrH/5b354tGjGk4u2BSjFaQn3XrkTYHmGo= Received: by 10.229.52.148 with SMTP id i20mr4384079qcg.81.1323281468069; Wed, 07 Dec 2011 10:11:08 -0800 (PST) Received: from [192.168.1.68] ([68.64.144.221]) by mx.google.com with ESMTPS id h9sm4693346qac.13.2011.12.07.10.11.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Dec 2011 10:11:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 In-Reply-To: Date: Wed, 7 Dec 2011 13:11:06 -0500 Cc: internals@lists.php.net Content-Transfer-Encoding: quoted-printable Message-ID: References: <9570D903A3BECE4092E924C2985CE4853994C39F@MBX202.domain.local> <34B6F836-CC50-4470-AD5F-C6F8C471FC65@gmail.com> To: Rasmus Schultz X-Mailer: Apple Mail (2.1251.1) Subject: Re: [PHP-DEV] Patch: getters/setters syntax Implementation From: will.fitch@gmail.com (Will Fitch) The difference being *where* the functionality gets mapped. It's not = about making something "look like something else", it's about requiring = more userspace definitions. Functionality within get {} and set {} can = (and should IMO) be implemented outside of userspace code. Whether that = means another union within op_array or a completely new structure mapped = to a property zval and bitmap added to the zend_uchar type identifying = it as an accessor.... I'm saying be creative - don't just implement = something halfway for the sake of getting it done. =20 On Dec 7, 2011, at 12:50 PM, Rasmus Schultz wrote: >> if we're attempting to get around __set/get, let's not replace them = with > more method implementations >=20 > I don't understand this argument. Accessors are methods - making them = look > like something else won't change that fact. >=20 > In C#, type-hinted properties with automatic getters/setters actually > compile down to two method implementations, while implemented > getters/settings do the same, substituting "value" for whatever is = required > to access the auto-implemented backing field. >=20 >=20 > On Tue, Dec 6, 2011 at 9:26 AM, Will Fitch = wrote: >=20 >>=20 >> On Dec 6, 2011, at 8:58 AM, Rasmus Schultz wrote: >>=20 >>> I agree with all of those points - the extra indentation looks = messy, and >>> yes, type hints are important. It does fit better with PHP in = general. >>>=20 >>> It would be nice to also have support for automatic backing fields = in >>> addition though - so something simple like this: >>>=20 >>> class BlogPost >>> { >>> private $_author; >>>=20 >>> public get author() >>> { >>> return $this->_author; >>> } >>>=20 >>> public set author(Person $value) >>> { >>> $this->_author =3D $value; >>> } >>> } >>=20 >> I don't like this approach. All efforts (which I'm currently part = of) to >> implement type hinting return values will be compromised. If you = want to >> implement accessors, keep them within a syntax that makes sense. >> Personally, I support the C# style as much as possible. Methods are >> already overused for purposes they shouldn't be, so if we're = attempting to >> get around __set/get, let's not replace them with more method >> implementations. >>=20 >>=20