Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63447
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <507D3459.3020900@sugarcrm.com>
References: <9570D903A3BECE4092E924C2985CE485612B53E4@MBX202.domain.local>
 <507D24E0.9070203@sugarcrm.com> <CACxA8bkuNM98fMm948a=BrxVSjY3K0u9n74HMELuxZXWDHB0Pg@mail.gmail.com>
 <507D2C54.6030702@sugarcrm.com> <CACxA8bm8q4uFR5dWGOmvJYS_ofY3JDiOvzJn6bmyY_1sEdRBSg@mail.gmail.com>
 <507D3459.3020900@sugarcrm.com>
Date: Tue, 16 Oct 2012 03:22:59 -0700
Message-ID: <CACxA8bn_LAdp-xo8waZ7MW4G4cZNhO1=fmSH6iQeLh3T=1LGZA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Clint Priest <cpriest@zerocue.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8ff1c4b88090fd04cc2a8b19
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
From: tbprogrammer@gmail.com (Jazzer Dane)

--e89a8ff1c4b88090fd04cc2a8b19
Content-Type: text/plain; charset=ISO-8859-1

Stas, the proposed "solution" thus far is to make the getter or setter
final and private and not have a body. This would naturally throw an
exception if it was accessed from anywhere but the class it was defined.
The class it was defined in has to remember that it is virtually a
read/write only accessor.
Although it has not been proposed yet, perhaps the above can be further
enforced by automatically throwing an exception whenever a getter/setter
exists but does not have a body.

Nevertheless, the "solution" is, as you can see, pretty loose right now,
and I definitely wouldn't object to hearing and discussing alternative
proposals.

On Tue, Oct 16, 2012 at 3:18 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > In regards to #11, yes, you'd just write {}. I imagine you could also
>
> This doesn't work for the same class (and for traits which put things in
> the context of the same class) - it would not behave as "no setter", it
> would behave as "there's a setter doing nothing". Is this the proposed
> solution?
>
> Exception is a possibility but then everybody would do it differently
> which reduces the value of standardizing it (the whole point of having
> accessors since otherwise we could just do __get and throw exceptions).
>
> > We went through multiple alternative options to read/write-only, and the
> > implementation you see in the 1.2 RFC is the most widely agreed upon
> > proposal. I don't doubt that there is room for improvement in this area,
> > but we haven't had any further proposals as of yet.
>
> Actually, I do not see anything explicitly said in the proposal that
> works for the cases outlined above. I wanted to just make sure if that
> means "no solution currently" (then should be on TODO list) or "we have
> a solution but it's not outlined in the RFC" (should be added then).
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

--e89a8ff1c4b88090fd04cc2a8b19--