Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84644
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
Message-ID: <5501C4FF.4050709@garfieldtech.com>
Date: Thu, 12 Mar 2015 11:55:27 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <ff8e8d5564b00b7baead3d9dd46282c8@mail.gmail.com> <CAEZPtU6wQtLeotvsCShHkU2g+Fo115b7NUGfAGvu88FyH-odrw@mail.gmail.com> <550149E1.9030904@olemarkus.org> <b294ef96e9d5a5fb9747530d1c7523e5@mail.gmail.com> <5501582A.7020905@lsces.co.uk>
In-Reply-To: <5501582A.7020905@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
From: larry@garfieldtech.com (Larry Garfield)

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