-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Mike Lively wrote:
| in the neck to use effectively. If you start using 'int' type checks for
| functions you are going to want to be passing data from _GET, _POST, etc
| to, you will have to do is_numeric checks or something similar, so
| instead of saving this userland code (like people are arguing scalar
| type hints will do) you are just moving that userland outside of the
| function into the code calling the function. That doesn't seem like much
| of a win to me in the ease-of-use regard.

In my view, hinting is *not* something you want to use for functions
having to deal with input parameters directly. You're not the first to
mention such example on this list. It doesn't make sense for this case,
which is basically everyone saying here (correct me if I'm wrong).

I see the benefits in applications/libraries/components with many
layers/interfaces/external libraries to make sure that int is int is an int.

I'm also not a fan of type conversion with type hints. I've a library
which is supposed to take an integer as a parameter and someone passes a
string, see this case:

class lib {
~  function fromIndex(int $index) {
~    // make proper range check anyway
~    return $this->aArray[$index];
~  }
}

$string = "something";

// ops, MY error
lib::fromIndex( $string );

$string would be happily converted to an int of value 0. In my eyes,
this is a big problem and not something I would expect with type hints.
I expect an E_RECOVERABLE_ERROR (or, ideally, an exception, but we're
far from that road) which I deal with appropriately. Be nice to the
developer and, when we can, tell him about an error he made. "He, you're
a nice guy, still the developer intended to only accept an int and you
passed in a string; check your code!"

Of course, if I make $int = 0; and pass $int to the function when I
actually meant $int = 1, it's my fault too.

There's nothing we can prevent from the latter error, but we can prevent
from the former. And my opinion is, that we should.

Let type hints optionally help developer who want the, without magic
conersions.


- - Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHgCw/1nS0RcInK9ARAmwWAJwNnT751atoZ9J8ciop1PFbQJZ9mwCgqAPH
qd6oby/Se/HQlNnpudI7rKY=
=E2lh
-----END PGP SIGNATURE-----

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to