Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63456
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 207.97.245.193 as permitted sender)
Message-ID: <507D3F8A.5040402@sugarcrm.com>
Date: Tue, 16 Oct 2012 14:05:46 +0300
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Clint Priest <cpriest@zerocue.com>
CC: "Nikita Popov (nikita.ppv@gmail.com)" <nikita.ppv@gmail.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <9570D903A3BECE4092E924C2985CE485612B6466@MBX202.domain.local> <507D2AB5.1000903@sugarcrm.com> <9570D903A3BECE4092E924C2985CE485612B6C88@MBX202.domain.local>
In-Reply-To: <9570D903A3BECE4092E924C2985CE485612B6C88@MBX202.domain.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2 : Interfaces
From: smalyshev@sugarcrm.com (Stas Malyshev)

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?

> 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.

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?

> 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.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227