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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
