Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63445
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <507D2C54.6030702@sugarcrm.com>
References: <9570D903A3BECE4092E924C2985CE485612B53E4@MBX202.domain.local>
 <507D24E0.9070203@sugarcrm.com> <CACxA8bkuNM98fMm948a=BrxVSjY3K0u9n74HMELuxZXWDHB0Pg@mail.gmail.com>
 <507D2C54.6030702@sugarcrm.com>
Date: Tue, 16 Oct 2012 03:02:41 -0700
Message-ID: <CACxA8bm8q4uFR5dWGOmvJYS_ofY3JDiOvzJn6bmyY_1sEdRBSg@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=e89a8ff1c1466b21f004cc2a42d6
Subject: Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
From: tbprogrammer@gmail.com (Jazzer Dane)

--e89a8ff1c1466b21f004cc2a42d6
Content-Type: text/plain; charset=ISO-8859-1

In regards to #11, yes, you'd just write {}. I imagine you could also just
throw an exception. Maybe an exception could be thrown automatically if
there is no code between the braces. Though this doesn't really directly
relate to providing the ability to disable get/set in an accessor.

The only class that would ever be able to logically attempt to use the
empty getter/setter would be the very one that you define the accessor in.

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.


On Tue, Oct 16, 2012 at 2:43 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > #5: From what I understand, an extending class can not override an
> > accessor with a non-accessor.
>
> This should be in the RFC then - along with what exactly happens. Note
> that this will represent a sort of BC break in terms that you could have
> two properties $a before, but if you change implementation of $a in base
> class from plain old property to accessor property, the child class
> would break. Which is not good, since compatible changes in parent class
> should not break child classes - and which will also impede adoption of
> this feature, since you can not guarantee no child class does it.
>
> > #11: If you set an accessor's get or set to /final private/, you are not
> > able to extend and it are only able to invoke it from the current class.
> > If you don't invoke it, then it is virtually read or write only.
>
> I get this, but what do you write as a method body if you want to just
> disallow it? Do you write just {}? Then it's not good for get() since
> get() is supposed to return a value, and also not good for set() since
> base class still can call private methods, and we want set() to be not
> available for everybody.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

--e89a8ff1c1466b21f004cc2a42d6--