Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64523
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 67.200.53.250 as permitted sender)
Message-ID: <50E6F2EB.20108@zerocue.com>
Date: Fri, 04 Jan 2013 09:19:07 -0600
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Levi Morrison <morrison.levi@gmail.com>
CC: Nikita Popov <nikita.ppv@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAF+90c_girfbcPBb8rCV3bPNR2Hsd5gyRPB+VArCfqjPPqG5DQ@mail.gmail.com> <CAFMT4Np7knN1xS+wmeS=4ToVDZ2hryCd8K1yOUox+ubVoaX=Hg@mail.gmail.com>
In-Reply-To: <CAFMT4Np7knN1xS+wmeS=4ToVDZ2hryCd8K1yOUox+ubVoaX=Hg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------050208080404090608030208"
Subject: Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
From: cpriest@zerocue.com (Clint Priest)

--------------050208080404090608030208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This shouldn't be an issue because it is not possible to set the 
property without going through the setter, which would be a type hinted 
accessor function.

Ergo, an attempt to set the value to an invalid value would cause a 
fatal error and thus the setter would not be able to then set it to the 
invalid value.


On 1/4/2013 9:15 AM, Levi Morrison wrote:
> This proposal looks really good to me. It cuts out a lot of syntax and
> boilerplate for a commonly used case. However, there is one issue that
> I know somebody is going to raise:
>
> Argument: If you change the value of the property without using the
> setter then `get` could return something that has a type mismatch with
> the type-hint.
>
> If I understand the current RFC for properties correctly, the only
> place that a property can be directly written to without the accessor
> is inside of the `__setProperty` method. This almost nullifies the
> argument completely.
>
> The only other place for possible error would be assigning a value in
> the constructor that does not match the type-hint.  However, because
> we adding a new syntax we *could* disallow assigning a value if it
> really was that problematic. I do not personally feel that would be
> necessary.
>
> I feel that this argument is not weighty enough to stop the proposal
> for this improved syntax.
>

-- 
-Clint

--------------050208080404090608030208--