Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces

[David Muir]

On 16/10/12 22:34, Clint Priest wrote:

-----Original Message-----
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Tuesday, October 16, 2012 6:06 AM
To: Clint Priest
Cc: Nikita Popov (nikita....@gmail.com); internals@lists.php.net
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces

Hi!

that supports properties in interfaces.  Again, not exhaustive either
but there is one language that does support accessors in interfaces
and that's C#.
So what C# does when mixing regular properties and accessorized properties?
I'd have to do some research to know for sure, but it's highly likely that they 
cannot be mixed.
Think about it, if you allowed an outside caller of your class to
modify your internal state, any time you needed to use that internal
state you would have to validate it before you could rely upon its
value to be set correctly.  No such issue exists with accessors in an
I do not see why this assumption is made that I need to do some special 
validation each time state is changed. In fact, in 99% of
existing code it is not happening, and I assume this ratio will be kept even 
when accessors are available. Most code will be very
straightforward, not doing anything complex with the state.
If you have a public property $a which internally can only deal with it being 
set to 2 or 3 and someone external to the class sets it to 4, your class either 
has to check that it's 2 or 3 and deal with the fact that it is now 4 or have 
indeterminate results when it is set to 4.

Now, I think the bigger question is: what exactly you want to say/require when 
you write:

interface a { public $xyz { get; } }

and what is the use case for this requirement?
The use case is that you are declaring that interface a must allow a property 
$xyz to be readable and *not* writable.

Just to be a bit more concrete here, as the code is presently written
and because I have strongly separated the concept of a property vs an
accessor, this code:

interface a { public $xyz { get; } }

class b implements a { public $xyz; }

Produces the following error: Fatal error: Class b contains 3 abstract
accessors and must be declared abstract or implement the remaining
accessors (get a::$xyz, isset a::$xyz, ...) in %s on line %d
I think this is wrong. 3 abstract accessors is especially wrong since it 
doesn't match the direct interface definition and is very
confusing (see my earlier point about isset/unset always having fallback 
defaults) but even with get as abstract I do not see a valid
use case that would require such behavior. What you want is for any $foo that 
is instanceof a to be able to respond to read request
to $foo->xyz, right? Class b satisfies this requirement, why you reject it then?
Also, if you reject it - how I should fix it to make it work? Would I have to 
implement a bolierplate getter/setter just to make
interface work? Doesn't look like a good proposition to me.
Class b does not satisfy the requirement because you are missing the fact that 
public $xyz { get; } forbids setting of $xyz, only reading it.


That doesn't make sense. An implementation has to have the same or less 
restricted visibility, so the above should work. The inverse however 
should not:

interface a { public $xyz; }

class b implements a { public $xyz { get; }}


Daivd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php