2008/5/12 Marcus Boerger <[EMAIL PROTECTED]>:
> 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.
For scalars and accessible properties, unset() does indeed undeclare
the scalar/property.
<?php
$foo = 'bar';
echo $foo;
unset($foo);
echo $foo;
?>
results in Notice: Undefined variable: foo in C:\- on line 5
and
<?php
class foo {
public $bar;
public function __construct() {
$this->bar = 'snafu';
}
}
$o_Foo = new foo();
echo $o_Foo->bar;
unset($o_Foo->bar);
echo $o_Foo->bar;
?>
outputs ...
snafu
Notice: Undefined property: foo::$bar in C:\- on line 13
But if the property is part of an interface, then allowing the
property to be undeclared would seem to me to be breaking the
contract.
Say $bar is in iFoo.
We would expect if ($someobj implements iFoo) then $someobj->bar to
exist. The interface says it does. If it has been removed, then the
interface is lying or the contract isn't as strong as is expected.
If we are saying that unset() on an interfaced property works
differently to unset on scalars/normal properties then seems
potentially confusing.
Richard.
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
