Re: [VOTE][RFC] Coercive Scalar Type Hints

On 3/12/15 4:11 AM, Lester Caine wrote:

On 12/03/15 08:29, Zeev Suraski wrote:

There have been NO big changes to the proposal - only two tweaks which I clearly detailed in the Vote email, that have been publicly discussed in detail on internals@ more than a week ago.

Zeev ... being realistic I think that the chances of getting another 48 votes in favour are unlikely as are the chances of blocking the other proposal? The problem here is that a large number of people want type hinting one way or another and there is not a strong enough case being made NOT to bow to that will? So the next problem is perhaps how do we live with a section of the developer world adding hints to well established libraries? During the move to PHP5 one could quite happily write code that continued to work on the majority of PHP4 systems, The move to PHP7 needs the same set of guidelines, so what is currently being championed which will mean that we have to maintain a PHP5 version of a library from day one of PHP7 and what do we avoid in order for PHP code still to run on PHP5?

Code with type hints won't be valid on PHP 5 period, no matter what approach we take. Making internal functions pickier about their existing typing doesn't make writing PHP5-compatible code impossible, it just means you have to be more careful about weird and probably-buggy cases like number_format("101 dalmatians"). As Zeev noted, most of the places that these changes caused an issue are likely existing bugs in the first place, so the PHP 5 code would become better by being PHP 7-compatible.

The bit I am more concerned about is the further dilution of the docblock annotation as people will adopt type hints in place of the already existing annotation and again we loose a lot more than we gain :( Personally I would much prefer that this was picked up properly again as other RFC's are trying to do, and I feel that answers all of the type hinting ad other static analysis problems that some people seem to think are so important. Expansion of the docblock 'standard' will also allow range of variables to be managed, yet the whole lot can be striped and ignored once one is out of 'design' phase.

We don't lose anything by type information moving from a docblock to the method signature itself, and in fact we gain a great deal as has been discussed to death in this thread. We already can have whatever type information you want in docblocks, but that means diddlysquat for the compiler or runtime. This whole paragraph is a red herring.

Is the final endpoint target here that like python, PHP will become a two stage process with compiled versions of user land code?

With an opcache built into core and discussion of it moving into the engine I think that's a given, in practice. That's entirely unrelated to typing, though. --Larry Garfield