On 12/03/15 16:55, Larry Garfield wrote:
> 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.
If type hinting is NOT used at all, then the code should run on PHP5?
The question is just what does one have to avoid to remain PHP5
compatible, and more important just how does one avoid some third party
use of it getting in the way.
>> 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.
The whole argument about adding type hinting revolves about red
herrings. There is nothing stopping someone using static analysis on
well written and documented PHP5 code today without affecting everybody
elses use of that code.
>> 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.
Again much is being made of 'optimizing at compile time' a term which I
simply don't recognise. If one has a script that is running ... it's
running ... and loading it up with more switches is detracting from
performance ... unless there is caching already running?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
