Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64522
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c_girfbcPBb8rCV3bPNR2Hsd5gyRPB+VArCfqjPPqG5DQ@mail.gmail.com>
References: <CAF+90c_girfbcPBb8rCV3bPNR2Hsd5gyRPB+VArCfqjPPqG5DQ@mail.gmail.com>
Date: Fri, 4 Jan 2013 08:15:55 -0700
Message-ID: <CAFMT4Np7knN1xS+wmeS=4ToVDZ2hryCd8K1yOUox+ubVoaX=Hg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>, Clint Priest <cpriest@zerocue.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
From: morrison.levi@gmail.com (Levi Morrison)

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.