On 22 January 2013 08:15, Lars Schultz <lars.schu...@toolpark.com> wrote:
> Am 22.01.2013 09:07, schrieb Nikita Popov:
>
>> It's not just about the lines of code. It's about having a more readable
>> and more intuitive syntax. Am I the only one who thinks that "public $date
>> { get; set(DateTime $date); }" looks pretty ugly/unclear compared to
>> "public DateTime $date;"?
>
>
> FWIW: I agree;) If accessors get through, I'd rather have this alternate
> syntax. The other looks like a typo. I don't get to vote though...I'm not an expert, so I may be getting the wrong end of the stick. If you type hint the property, you cannot supply anything but that type when you set it? Where as, if you type hint the set parameter, you can supply that type, and have the set method extract/perform whatever is required and assign that result to the local property, which may be of a different type. I would assume that the property has it's own docblock to reflect the stored type. Of course, I certainly see a bad case of confusion being presented here if the stored type and the set type are different. And it would seem that type hinting the property would solve this, but you know developers will always want to get around blocks, is there any sensible use case for having type hinted set() parameter as well as type hinted property? Richard. -- Richard Quadling Twitter : @RQuadling EE : http://e-e.com/M_248814.html Zend : http://bit.ly/9O8vFY -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
