Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75425
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
Message-ID: <53C2AF35.40003@gmail.com>
Date: Sun, 13 Jul 2014 17:09:25 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <CAF+90c-ojALBgeyXu+f2tW6LoW8+4XGVpu_+i9SyX=u4RSoxug@mail.gmail.com> <027E65EF-C4FC-474C-92BB-D99EFADDEEED@ajf.me> <ada4093ad61814c182f8ca31939962ea@mail.gmail.com> <BDC11A4E-0610-49A3-B8AE-E9D3627B75C8@ajf.me> <eab1ceea2084415d21736a69c4ac6fdc@mail.gmail.com> <53C29EE4.3090808@gmail.com> <63e5b1c38d6e0c5111987e78d9b59be3@mail.gmail.com> <E2926DD2-B0AE-4A87-BEA8-F07FE49CE4B5@ajf.me> <b3026b451453e3c2412bbf45c59f5003@mail.gmail.com>
In-Reply-To: <b3026b451453e3c2412bbf45c59f5003@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: rowan.collins@gmail.com (Rowan Collins)

On 13/07/2014 16:45, Zeev Suraski wrote:
> Even reading Nikita's piece, he's saying he dislikes that option for
> 'obvious reasons', but I see nothing obviously wrong with this approach.
> [...] Unlike what's suggested in that piece, it's
> not equivalent at all to docblocks, as it is in fact enforced, and as you
> said, has the benefit of being able to write the 'inner code' without
> worrying about the input types.

I think you're muddling two sections of Nikita's article [1]. The option 
which is dismissed "for obvious reasons" is "unenforced type hinting" - 
keywords which do absolutely nothing other than give a literal hint to 
non-critical tools like documentation and reflection.

The next section is about "casting weak type hinting", which is 
described as "one of the more interesting proposals". It certainly has 
merit, although in my opinion it's less powerful than the other options 
in what it adds to the language, as the equivalent userland boilerplate 
is really minimal (e.g. $foo = (int)$foo).

As I've mentioned elsewhere, and indeed was mentioned in Anthony's 
proposal at the time [2], the addition of warnings on lossy casts is a 
completely separate issue to the ability to sugar those casts into a 
function signature.

Now, what is being proposed here is effectively "casting strict type 
hinting", a variant of what Nikita called "strict weak type hinting", 
with the additional step of actually applying the lossless cast, rather 
than just asserting that it's possible. This actually provides a lot of 
functionality which is fiddly to implement in userland, and I can't see 
a lot of uses for asserting that a cast would be non-lossy, if you're 
not about to perform that cast (which is what "strict weak type hinting" 
allows).

[1] 
http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-harder-than-you-think.html
[2] http://blog.ircmaxell.com/2012/03/parameter-type-casting-in-php.html

-- 
Rowan Collins
[IMSoP]