Re: [RFC] Type hints (parameter and return value)

On Thu, Apr 17, 2008 at 8:41 PM, Stanislav Malyshev <stas@zend.com> wrote: > > is_* are the important functions, since they are the ones which most > > resemble the type hints under discussion. Up until now, anyone > > Circular argument here. Yes, I phrased that badly. I believe it is fair to say that there would be confusion over why is_int may fail after an 'int' type hint. More generally, I think it is difficult to explain why an int type hint does not guarantee an int. > > implementing this in user-land would use is_int(). It makes perfect > > No, you shouldn't do that - there's absolutely no reason to accept 1 and > reject '1', unless you have some very rare and special circumstance. If you > are using is_int for that, your code is wrong. That is very subjective. I doubt there is 'one true style' of PHP, despite suggestions I see about 'the PHP way'. But let us suppose you would use an int cast instead to ensure you have an int (by type, not coerced value). The behaviour I recommend is also consistent with casting. It would be syntactic sugar for function ($x) { $x = (int) ($x); ... } > > sense that type hints should mimic this behaviour. Not doing so would > > be very inconsistent, and so confusing. > > > > Could we stop using word "consistent" to replace "I like it"? I am very deliberately not using "consistent" to replace "I like it", except in the sense that I like consistency. It makes no sense to find that you do not have an int, when you specify you must. I very much mean consistency, and do not have a preference for the approach, except that only one seems perfectly consistent in this case, which is why I have recommended it. Paul -- Paul Biggar paul.biggar@gmail.com