> -----Original Message----- > From: Rowan Collins [mailto:rowan.coll...@gmail.com] > Sent: Sunday, July 13, 2014 7:09 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening) > > 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.
You're absolutely right. My bad. BTW, auto-converting type hints were proposed by Lukas and me back in 2010, even though I see them attributed to Anthony in 2012 :) > > 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). That's not a bad thing in my book - another way to describe it is that it's consistent with the rest of the language and doesn't require developers to learn another new set of 'similar, but different' semantics. In terms of value that it does bring to the table, it gives you a standard way to do something that's very common in a shorter way and increases quality of APIs (it's much more likely people will use this to describe their APIs than docblocks), and we can use better warning semantics than we currently have on conversions (without changing the rules), and it allows you to do all that without having to add tons of defensive code (in the calling code) that is often unnecessary. Making it easy to implement means it'll get used more - and so far I fail to see what we stand to lose (more on that below). > 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. I don't see why they would be separate, especially if the key reason for going for 'option #3' is that it helps find bugs better. Option #1 with the added logic of warning about lost data or 'bogus' conversions has all the advantages of option #3 but also other advantages. > 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). Again, option #1 as I see it (and is mostly described in the 2010 RFC https://wiki.php.net/rfc/typecheckingstrictandweak) - it's identical in terms of rules to those of PHP's casting, but with warnings emitted for lost data and 'bogus' conversions. If we introduce this feature in a major version, we could also consider change the casting code to emit these same warnings so that we get full consistency - but that I think is in fact a separate decision. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
