On Monday, January 2, 2012, JS wrote:
> I think the proposed syntax will create a lot of code readability issues.
> Have you considered an alternate syntax:
>
What readability issues? The proposed syntax matches that of C# and Java.
The idea is to use a syntax already familiar to most developers.
>
> public function ($a, $b) returns nullable ClassName {
>
> }
> Or any other variation that puts the return type after the function name
> /paramter list. Some advantages:
>
> 1) The function keyword is dealt with gracefully
>
The function keyword is already being discussed as being removed for
methods. See https://wiki.php.net/rfc/optional-t-function
>
> 2) I imagine it would be easier for the parser
>
Your proposed alternative would create an additional token "returns" and
add the additional step to check *after* the method/function has been
declared. The syntax in the RFC just replaces an existing token, making
the check almost nothing, in terms of additional checks.
>
>
> 3) it is easier to extend that syntax if ever in the future the
> functionality expanded
>
>
How does it make it easier to extend? Let's say we add exception labeling:
public function something() returns SomeClass throws Exception
To me, this looks much more elegant:
public SomeClass something() throws Exception
This requires much less typing and would match the already defined
syntactical approach by Java.
> 4) most importantly is it is very readable when scanning code. When a
> programmer is scanning code
> usually the function is most important and not the return type. Imagine
> some frameworks, like Magento, with the proposed syntax
> and the readability issues it will provide with 50 methods in a class with
> variable length return type declarations:
>
>
> public nullable Mage_Core_Model_Core_Resource_Collection_Abstract
> example() {
>
> }
> Versus:
>
> public example() returns nullable
> Mage_Core_Model_Core_Resource_Collection_Abstract {
>
> }
>
>
I don't see how you feel that makes things more legible. Again, developers
familiar with languages outside of PHP are already familiar with the
proposed syntax.
If the majority of folks out there would rather see this approach as
opposed to the C#/Java style, I'm open to modifying the patch to do so.
However, adding an additional token will cause additional time.
--
Will Fitch
Zend Certified Engineer
931.205.8242
