Hello Richard,
Wednesday, May 7, 2008, 3:33:24 PM, you wrote:
> 2008/5/7 Jeff Moore <[EMAIL PROTECTED]>:
>>
>> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
