Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37623
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Tue, 13 May 2008 15:53:02 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <721653902.20080513155302@marcus-boerger.de>
To: "Richard Quadling" <rquadling@googlemail.com>
CC: "Marcus Boerger" <helly@php.net>, "Jeff Moore" <jeff@procata.com>, 
	"Lars Strojny" <lars@strojny.net>, 
	"John Carter -X (johncart - PolicyApp Ltd at Cisco)" <johncart@cisco.com>, 
	"Derick Rethans" <derick@php.net>, <internals@lists.php.net>
In-Reply-To: <10845a340805120803k2587870bnf890ce44765f5e97@mail.gmail.com>
References: <48169695.9040803@omegavortex.net> <7dd2dc0b0804290817v3d8de030y1208a88f78c44411@mail.gmail.com> <BADE85FDE9053E4AAEC411E40C77C2911A68FC@xmb-ams-33e.emea.cisco.com> <862660524.20080506162159@marcus-boerger.de> <912CE6DE-22D0-43E6-BB6B-6154980050E5@procata.com> <1210101672.3952.4.camel@localhost> <489751132.20080506214551@marcus-boerger.de> <CC6F77E6-FA3C-4CE9-A82D-D3686A4AA4BD@procata.com> <10845a340805070633q2316a598lc1a69f259c523341@mail.gmail.com> <92634160.20080512164700@marcus-boerger.de> <10845a340805120803k2587870bnf890ce44765f5e97@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,

Monday, May 12, 2008, 5:03:39 PM, you wrote:

> 2008/5/12 Marcus Boerger <helly@php.net>:
>> Hello Richard,
>>
>> Wednesday, May 7, 2008, 3:33:24 PM, you wrote:
>>
>>> 2008/5/7 Jeff Moore <jeff@procata.com>:
>>>>
>>>>  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