On Thu, 2008-01-03 at 21:34 -0800, Andi Gutmans wrote: > 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.
It doesn't fit. This is not a technical argument, this is your opinion on the way PHP should be. That's the problem here. > 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! We keep saying that scalar type hinting is not intended to be used for input. Even so, if you really wanted to you could run your input through a very simple function and convert each variable into the appropriate type. function typeConvert($variable) { if (is_array($variable)) { foreach ($variable as $k => $v) { $variable[$k] = typeConvert($v) ; } } else if (is_object($variable)) { foreach ($variable as $k => $v) { $variable -> $k = typeConvert($v) ; } } else { if (is_numeric($variable) and substr($variable, 0, 1) !== '0') { if (substr_count($variable, '.')) { $variable = (float) $variable ; } else { $variable = (int) $variable ; } } } return $variable ; } > 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. I've said this numerous times too. How hard is it to understand? If someone can't understand this simple concept they are sure as hell not going to understand object oriented or anything. Plus the fact that this is actually easier to understand than array/object type hints. > 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. Well that's their decision. I could use functions and not use a single class in my applications, and they would be faster. I sacrifice a little performance in order to make my code better. > 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...) You are right here. But define bloatware. Type hinting is already in PHP. All I want to do is add a couple of types to this already implemented feature. My patch is pretty small. > 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. Good point, namespaces need to be tested and brought to a production state, and i18n looks pretty interesting. > 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. It's worked for me fine for a couple of months. The if statements in zend_compile.c are pretty confusing (as far as the brace indentation goes). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
