Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83069
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender)
Message-ID: <54E4A246.9040405@gmail.com>
Date: Wed, 18 Feb 2015 14:31:34 +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>	<CAPwsocFUF9WcTxc-BjmaCccdPbeYs5VgyDvqYbx=3cR-SwoPkg@mail.gmail.com>	<54E49135.60907@gmail.com> <CAPwsocFSgaqmazRV+g93i8Oryj9mC+VwYzup5DCoRUzLZfhPdg@mail.gmail.com>
In-Reply-To: <CAPwsocFSgaqmazRV+g93i8Oryj9mC+VwYzup5DCoRUzLZfhPdg@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)

Leigh wrote on 18/02/2015 13:31:
> On 18 February 2015 at 13:18, Rowan Collins <rowan.collins@gmail.com> wrote:
>>> 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.
> 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?


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.


>
>>> 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.
> 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.

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]