On Sat, Jun 30, 2018 at 3:08 PM, Stanislav Malyshev <smalys...@gmail.com> wrote: >> Together with Michael Moravec, we’d like to announce that we are pretending >> to open the Mixed Type RFC (https://wiki.php.net/rfc/mixed-typehint) next >> Monday (02/07) and we’d like to ask you to take a look into the PR on >> GitHub (https://github.com/php/php-src/pull/2603) and let us know if >> there's something else to do before it. > > I think this is wrong. This "type" - which is not really a type, of > course - does not add anything to the code, by definition - if you take > it out, everything would be the same. Things like that belong in the > documentation. Moreover, it makes the code harder to read, as the reader > should make mental effort to discard this non-type every time it is > mentioned, as it does not carry any information. > I would say that, in a world without union or intersection types, it adds to the readability of the code by explicitly saying, "We accept more than one type here, and we know we accept more than one type here." This is distinct from, "We have no idea what type we accept here." That adds to readability, it doesn't detract.
I preface that with a mention of union/intersection types because that seems to be the *actual* problem this RFC is attempting to cope with while lacking the tools to do it right. I'm not super excited about this RFC because, as you say, this information could be easily encoded into the docblock for the function/method. Zero impact to the syntax, same benefit for the programmer and their readability. (More benefit, really, as docblock standards *do* permit union/intersection types. So, complex types maybe? -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
