On Tue, 2008-01-08 at 22:47 +0200, Tomi Kaistila wrote:
> > 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.

Ok, but a scalar becomes useful for a couple of important things.
Scalars are all displayable values, that can be stored in a db,
outputted, etc. The scalar type hint prevents errors related to objects,
resources, and arrays attempting to be stored in the db or echoed.

> 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

Reply via email to