On 1-Jul-09, at 10:35 PM, Paul Biggar wrote:
- A strong argument against (C) is that this currently has no parallel with how scalars are handled in PHP currently.
It does not need to have a parallel. PHP as a rule is a type flexible language, my intention is not to change that, simply provide developers with yet another tool they can use to make their life easier and not break anything for people who already use PHP and don't want/need type hinting. The way current internal functions handle input should not change, since doing so will break nearly all existing code. We can provide means for authors as Hannes had pointed our earlier, of new extensions and if we choose to allow it internal methods/functions to have script type hints, but IMHO that only makes sense for future code.
- An argument for (H)/(S) is that the manual has been written in this style, using this syntax.
Manual has nothing to do with this, manual describes native(!!) PHP functions that should not implement type hints unless we as a team all decide to make PHP type strict, which I don't think is such a good idea.
- The (C) crowd suggested numeric and scalar to the (H) crowd, but I dont think they were impressed.
If you don't use numeric type for native PHP functions you will break lots of existing code. Remember the goal of this excursive is not to change the nature of PHP, but rather provide a non-destructive feature for people who see the benefit in type hinting within their own code.
- I dont think there is a strong case for a strongly typed bool.
If function returns -1 on error bool cast will convert it to true, which may not be intent.
Look guys, I have been using type hints for quite a long time in PHP, something I doubt most developers here can say. It does not mean people should agree with me or implies that what I say is right, but give the following a bit of consideration before listing your objects.
1) Strict type hinting helps to solve bugs, both the ones made out of careless/missing validation as well as subtle logic bugs that often take hours to resolve. I can tell you that within a week of implementing type hints we've been able to identify 30-40 bugs within a period of day. Many of which would not have been detected with "flexible" type hints that Paul is suggesting here is one example:
A developer was doing "select * from table" and then using PDO fetchColumn(), on the dev environment table structure was such as the 1st column was a numeric primary key and all worked well. However, in production the order of columns was different and the returned value was actually a login name (varchar), since they happened to be numeric in nature code worked but operated on the wrong ids. It was a very subtle bug that strict type hinting identified instantly and probably saved at least hour's worth of code review.
2) Type hinting will not create a mess of cast to the right types in the code as Stas had suggested, in close to a million lines of PHP code we have, I've been able to find less then 1000 (just did a grep) instances of casts. There is a good reason for that once you get out of the input processing stage you typically (aside from __toString()) have the data in the right type. The code also includes bits from PEAR and external libs like fpdf and guess what those have no type hints and they work along side with type hinted code without any issues. Why? Well, when developers intend to return an int or a float or a boolean, they rarely convert to a string just because they can.
3) Lets not forget that PHP has always been about giving as many tools as possible to our users to help them solve various problems. When I decided to post this patch on this list, thanks largely to encouragement of fellow developers, I've also thrown it on my blog to see what users of PHP think and see if perhaps my specific use case is not applicable in common situations. Of all the replies I see no objection so far and the only complaint (funnily enough) is about existence of IS_NUMERIC.
I do not wish to start a flame war or arrive at a wishy washy compromise that does not provide a solid solution. If the majority disagrees with the idea, that's perfectly fine, no harm no foul, I'll keep patching my PHP locally and if I have time maintain a type hinting patch outside of "stock php" for people to use. But please, don't reject this idea because you personally don't see yourself using it or because you want to avoid having to work in a future with a library/framework that is strict about its input or some far fetched idea that it will change the very nature of PHP.
Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
