On Thu, Apr 17, 2008 at 8:41 PM, Stanislav Malyshev <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
