Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83046
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.177 as permitted sender)
Message-ID: <54E47725.4060801@gmail.com>
Date: Wed, 18 Feb 2015 11:27:33 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAESVnVoZYiMWQk1Ydc-9wbkJo7Ru_4mrUtrubW=Rh=QKK9o8TA@mail.gmail.com> <CAF+90c_S3xT07F-4smHeD=BTuSG9VQZxZ==mhyOzDuBw5QPX_Q@mail.gmail.com>
In-Reply-To: <CAF+90c_S3xT07F-4smHeD=BTuSG9VQZxZ==mhyOzDuBw5QPX_Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Scalar Type Hints v0.4
From: rowan.collins@gmail.com (Rowan Collins)

Nikita Popov wrote on 18/02/2015 00:35:
> I don't like the way this is heading with regards to internal functions.
> Apart from better inter-compatibility, the primary appeal of Andrea's
> proposal was that we have the option to make not only userland function
> calls strict, but internal ones as well. With these modifications this is
> lost for all practical purposes.

I actually rather like this idea - it allows internal functions to 
gradually introduce scalar type hints just as userland code will 
gradually introduce them, rather than assuming a new meaning of existing 
metadata. It gives a chance to look, for each function, what hints make 
sense, separate from the technical requirements of translating to a 
strongly typed set of C variables, which is the main role of ZPP.

Note that, however natural it may seem to core/extension devs, the 
workings of ZPP are not at all obvious to users, so the more 
similarities between internal and user-defined type hints, the better.

> Where "practical purposes" refers to my assumption that it is very
> unlikely that we'll add arginfo typehints to the entirety of all bundled
> functions and the added typehints will not be heavily colored by people
> trying to shove in weak typing even when strict mode is enabled.

I see it working well if a large batch of uncontroversial functions have 
type hints mechanically added straight away, and then more complex cases 
are looked at in detail and discussed via pull requests or similar.  
What you have identified there is a danger to be watched out for, 
certainly, but it is not an inevitable outcome, if we come up with a 
decent set of guidelines of how the feature should be used.

Regards,
-- 
Rowan Collins
[IMSoP]