We've discussed scalar type hinting many times in the past and decided against it. It really doesn't fit in very well with PHP's loosely typed nature which is one of the main reasons it has been so easy to use. The only reason why it works with classes and arrays is because those are unambiguous constructs.
Even this thread shows that there's no alignment between people on what it should actually do. This is due to the lose nature of PHP. For example, HTTP vars come in as strings. So if you have http://localhost/?n=1 in your URL there are some in this thread which would expect it to be successfully juggled by an "int" type hint even though it actually comes in as a string; and some who want it to be ultra-strict and if the PHP type isn't an integer it should emit an error. What happens when you pass an object with a __toString() method to a function expecting a "string"? I think it should work and convert. I am sure some here disagree. This is exactly the problem! Saying that it won't confuse newbies is also wrong. PHP is so popular because it's so easy for people to pick up. Part of this also includes ability to look at other people's code, understand it, copy-on-write (e.g. a Wordpress plug-in). The more features in PHP the harder it'll be for developers to deal with. Yes, we bit the bullet for namespaces because there were strong reasons in favor of it, we as a community had it on our wishlist for a long time and a lot of work went into it. And even when we did it we had to find a way to make it work for PHP. In this case, with the lose typing of PHP creating a consistent model which will be apparent to people without many questions is a big issue. Also, for those who say that when this feature is not used it doesn't have a performance impact that is also a problematic statement. If it exists people will use it. Most people using PHP don't understand (and shouldn't have to understand) how the language is implemented. It may very well be that even if we could agree on the semantics we'll see all sorts of developers "decorate" their code with type hints (because they think it'll help readability) who may down the road find themselves in a surprise when it comes to performance. Last, just because something can be implemented and a patch exists doesn't mean it should be in PHP. There are lots of things I can implement for PHP which shouldn't be in PHP. Also don't under estimate what happens when you get bloatware and over time how much harder it becomes to maintain and also how it does eventually end up slowing things down (over time there are more branches, more code a.k.a more cache misses, etc...) We have what I think is a very exciting PHP version coming up with 5.3. The featureset has been agreed upon. It'd be great if all the contributing energy in this thread could be channeled towards playing around with 5.3 esp. the new i18n extension, namespaces, help with migration/incompatibility notes and garbage collector benchmarks. We are now at the stage where we really need the code base to mature with feedback from users. The more you can invest in that the better. Ouch, sorry for the long email! :'( Andi P.S.- The runtime piece of this patch also looks wrong. I didn't dive deep but those if() statements don't look too friendly. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
