Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:37606 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36867 invoked from network); 12 May 2008 14:49:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 May 2008 14:49:57 -0000 Authentication-Results: pb1.pair.com smtp.mail=helly@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=helly@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender) X-PHP-List-Original-Sender: helly@php.net X-Host-Fingerprint: 85.214.94.56 aixcept.net Linux 2.6 Received: from [85.214.94.56] ([85.214.94.56:35869] helo=h1149922.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FA/D5-04596-11958284 for ; Mon, 12 May 2008 10:49:56 -0400 Received: from MBOERGER-ZRH.corp.google.com (59-188.79-83.cust.bluewin.ch [83.79.188.59]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by h1149922.serverkompetenz.net (Postfix) with ESMTP id CE5DE11F307; Mon, 12 May 2008 16:49:50 +0200 (CEST) Date: Mon, 12 May 2008 16:47:00 +0200 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <92634160.20080512164700@marcus-boerger.de> To: "Richard Quadling" CC: "Jeff Moore" , "Marcus Boerger" , "Lars Strojny" , "John Carter -X (johncart - PolicyApp Ltd at Cisco)" , "Derick Rethans" , In-Reply-To: <10845a340805070633q2316a598lc1a69f259c523341@mail.gmail.com> References: <48169695.9040803@omegavortex.net> <7dd2dc0b0804290817v3d8de030y1208a88f78c44411@mail.gmail.com> <862660524.20080506162159@marcus-boerger.de> <912CE6DE-22D0-43E6-BB6B-6154980050E5@procata.com> <1210101672.3952.4.camel@localhost> <489751132.20080506214551@marcus-boerger.de> <10845a340805070633q2316a598lc1a69f259c523341@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Class Properties in Interfaces? From: helly@php.net (Marcus Boerger) Hello Richard, Wednesday, May 7, 2008, 3:33:24 PM, you wrote: > 2008/5/7 Jeff Moore : >> >> On May 6, 2008, at 12:45 PM, Marcus Boerger wrote: >> >> >> > public $property { >> > __get = getProperty; >> > __set = setProperty; >> > } >> > string public function getProperty() { >> > return $this->_property; >> > } >> > string protected function setProperty(string $value) {} >> > >> >> Hi Marcus, >> >> I prefer this approach. >> >> One advantage is that it is compatible with existing classes that have done >> the getXXX() style accessors already. >> >> One thing That I am hoping to avoid, though, is the need to declare these >> kinds of basic accessor methods at all. (the ones that do nothing but set >> or read a backing property.) it seems like PHP should be able to generate >> them, or just fallback into a simple property access on the backing store, >> if that store is specified as part of the property. >> >> This should be the same as the previous example replacing setProperty and >> getProperty with direct references to the backing store: >> >> protected $_property; >> public $property { >> __get = $_property; >> __set = $_property; >> >> } >> >> >> > Or do we force people to always specify >> > get,set,isset und unset? Or should we only enforce get/set and have isset >> > and unset emulated with them (isset()~>isset(get()), unset()~>set(NULL))? >> > >> >> it would be nice to have exactly this emulation for __isset and __unset >> when they are not declared. >> >> However, leaving out the __set should make the property read only and >> leaving out the __get should make the property write only (less useful, but >> symmetric). >> >> Following the C# convention for declaring properties in interfaces would >> declare the previous as >> >> interface bar { >> public $property {__set; __get;} >> } >> >> Best Regards, >> >> Jeff > If the interface iFoo says property bar must be implemented, then it > would seem inappropriate to allow the unsetting of property bar. Why? Unset would simply set the storage to NULL, not undeclare it. > My reasoning is that the interface says this is how all objects > implementing this interface look (the contract), then allowing one of > the instances to remove the property breaks the contract. > If you follow this (I hope someone does), then as a consequence, isset > now becomes slightly different in that it is behaving more like an > empty(). > Regards, > Richard. > -- > ----- > Richard Quadling > Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 > "Standing on the shoulders of some very clever giants!" Best regards, Marcus