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

Reply via email to