On 24 January 2015 11:09:04 GMT, Robert Stoll <p...@tutteli.ch> wrote:
>Besides, pretty much the same impact has the return type RFC now, >because the manual should be updated accordingly to reflect the new >syntax IMO. Sounds like lot of work but it should be possible to >migrate the docs with a tool. As I said in another thread, updating the manual is nothing at all like changing the language. It is a single, centrally-controlled set of content, which doesn't have to be compatible with multiple environments, and has a minimum requirement of internal consistency which has been met in some cases with arbitrary conventions unrelated to the language. It may even be possible to change the notation without changing the source, by altering the output templates, but if not, an automated change to use a new convention more similar to new language syntax is a no-brainer. As for the rest, I don't see the pressing need to break a whole bunch of established syntax here. It will just make it impossible to run code under multiple versions, and brings a very minor benefit. I'm not even convinced that return types and parameter types are related enough to require consistency in an ideal world. The type hint to the left of a parameter is the type of that parameter, but a return type hint is not the type of the function - if the function were a first-class object, it's type would be "function", or a specific type such as "function(int, string): string". The function annotation means "produces a", not "is a". This isn't a theoretically rigorous argument, but to my mind it gives a sufficient reason for the syntaxes to be chosen independently. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
