Re: Types on the right or on the left
| From: | Rowan Collins | Date: | Sat, 24 Jan 2015 14:42:16 +0000 |
| Subject: | Re: Types on the right or on the left | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-81075@lists.php.net to get a copy of this message | ||
On 24 January 2015 11:09:04 GMT, Robert Stoll <php@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]