Re: Scalar Type Hints v0.4
| From: | Rowan Collins | Date: | Wed, 18 Feb 2015 14:31:34 +0000 |
| Subject: | Re: Scalar Type Hints v0.4 | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-83069@lists.php.net to get a copy of this message | ||
Leigh wrote on 18/02/2015 13:31:
On 18 February 2015 at 13:18, Rowan Collins <rowan.collins@gmail.com> wrote:Yes, I think that would be sensible. The aim would still be for most internal functions to have type hints by 7.0, since most of them have trivial signatures, particularly if we can agree a suitable set of union types. Internal function "signatures" (which are currently only signatures in the manual, and a bunch of procedural ZPP magic in the source) change between minor versions fairly often, so "function x will now raise errors in strict typing mode for values that would previously have been accepted" seems a reasonable change note for 7.1, 7.2, etc. I can't foresee any reason why we'd urgently want to add a typehint in a patch release. I can, though, see a rush to get every internal function typehinted by using ZPP causing unintended consequences, and us having to rush out fixes in 7.0.1.Of course, and some people may opt to avoid type hints altogether in their own code to avoid this, but they can't avoid changes to internal functions. How do we plan to release these incremental changes? We try and minimise BC as much as possible so a patch release might not be possible. Do we restrict it to minor versions, i.e. the yearly release schedule?This leaves us in a state where some functions will have defined types with their aggressive coersion rules and some will not, and we can't expect users to remember which set of functions have been updated or not.That's precisely the case for every existing user-defined function. Switching to PHP 7 won't suddenly add type hints to every function in every library and every existing bespoke code base, so there is no way to avoid that thought process.
Yes, I'm sorry, I deliberately took the sentence more generally than it was intended in order to make a different point. I find the lack of consistency between internal and user-defined functions really frustrating as a user, so am always on the look out for rules that can apply neatly to them both. Regards, -- Rowan Collins [IMSoP]That's not really what I meant. So a user doesn't have to keep track of which internal functions are now typed and which are not, all functions should be typed at the same time, or none at all.I think the rules need to apply to everything or nothing.The rules will apply to everything in the same way - if a function is typehinted, it behaves like so; if it's not, it behaves the same way it did in PHP 5.