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

Hi, [I'm replying also to Lukas email because of the similarity] Stanislav Malyshev wrote:

When you can use string but not object with __toString?

my patch does that

Ok, that's great. So then it makes sense to allow converting int->string too, right? And then it'd also make sense to allow string->int too? Especially if we have object->int convertor and that can be allowed too. In fact, we have good old conversion system used in parse_parameters. So why not use the same rules? That'd make at least some sense - give PHP programmers the tools that extension C programmers have. I still wouldn't like it too much but at least it would make sense :)

What would happen to that *type* itself, would it be converted when it gets into the function, is that what you're proposing? ------------------------------ $i = 5; function foo(string $s) { // $s implicitely gets "5" ? } foo($i); ------------------------------ I may be missing something but in this context, "string" doesn't get very useful (I think), because besides arrays / objects (except __toString), everything can be converted to a string, it isn't "type hinting" anymore but "type converting". What about I/O parameters? ------------------------------ $i = 5; function foo(string &$s) { // $s implicitely gets "5" ? } foo($i); // $i is now "5" ? ------------------------------ I think that's a major "wtf" factor. I also think for many people, including me who favor strict types, also see it as a helpful protection mechanism. During development it happens regularly that I mix up parameters, but still my code continues execution. Sometimes this can be fatal, wrong variable wrong value wrong place and suddenly I've values at certain code points I wouldn't have expected them there. user id instead of a name there, etc. Or when somewhere an external input leaks down into the code with a wrong type/value because it isn't checked anyway, suddenly a catchable fatal error is thrown and the application is (can be ...) automatically protected by not further executing it. sincerely, - Markus