> But the syntax is longer ("$a = 5" vs "$a = new Integer(5)"), and if you
> have a large application with hundreds of integers it starts to add up.
> Performance is also much worse when using objects for every variable.
I agree. That is what I meant by "ugly" and "clumsy" in my last post.> > This sounds like, at least, a partial victory to adding proper type > > hinting to PHP but in my mind it is not enough. I have counted that about > > a quarter of all type hints that I would make is about matching the > > argument's type to scalar. The rest are about separating specific scalars > > from each other. In most cases integer and boolean. > > Better than nothing. No, it is not. It is actually better to not fix it at all, if you cannot fix it properly. Especially in this case when the feature has already once been left "unfinished". The benefit is zero for me, if when I need to hint a boolean and can only hint a scalar. In that case, I will still have to do the validating myself. I might as well leave the type hinting out all together, instead of waste resources for having first PHP check that it is a scalar and then my own code to check that it is a boolean. Actually, if I can only hint "scalar" in general, I am essentially telling the users of my API that they should be ready for two types of errors. That which occurs when the argument is not a scalar and that which occurs when it is not a boolean. One will be a PHP error and the second will be an exception. Would be easier on them if I do not use type hinting at all in that case. I say, do it properly or do not do it at all. Tomi Kaistila PHP Developer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
