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