Hello Richard,
Monday, May 12, 2008, 5:03:39 PM, you wrote:
> 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
This is correct.
> 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
At this point you found an error. Because this allows unset() to modify an
instance in a way that it nolonger adheres to its class that means at this
point the following is nolonger valid: $o_Foo is-a foo. And that is the
basic design rule we chose for PHP. Please file as a bug!
> 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.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
