On 15 January 2015 19:20:27 GMT, Andrey Andreev <n...@devilix.net> wrote:
>Hi,
>
>On Thu, Jan 15, 2015 at 7:13 PM, Andrea Faulds <a...@ajf.me> wrote:
>>
>>> Now from that perspective I cannot rely that I am in strict and
>would have to handle the default weak even although I declared in my
>class that i wanted strict mode which only affected the code inside of
>that file. That's ultimately what I am saying and why I am stating it
>would have to handle both conditions. In reality, you'd always act as
>if you were in a weak mode supporting that case.
>>
>> I… really don’t understand, I’m sorry. Are you complaining that if a
>caller uses the weak mode, they are not bound by strict types? Why do
>you want to affect the code of the caller?
>
>Consider this badly designed API:
>
> declare(strict_typehints=TRUE);
>
> const MODE_APPEND = 0;
> const MODE_TRUNCATE = 1;
> const MODE_PREPEND = 2;
>
> function write_file(string $path, int $mode, string $data)
> {
> // it's quite obvious
> }
>
>Somewhere else, you forget the parameters order ...
>
> declare(strict_typehints=FALSE);
>
> $path = '/important/file.dat';
> $data = '1 year';
> $mode = MODE_APPEND;
>
> write_file($path, $data, $mode);
>
>It's a bad example - an awful (and indeed, very much useless) API,
>combined with an absent-minded consumer. Yet, it demonstrates how
>putting the caller in control *can* cause a disaster.
But, crucially, it causes a disaster *for the caller*. The library function
gets exactly the types it expects, and can happily pass them to some other
typehinted function, including an internal/extension function.
The "disaster" is that the effect is not what the caller intended, which would
be true for all sorts of other mistakes. No amount of strict type hinting will
solve my inability to remember whether strpos() takes haystack, needle or
needle, haystack.
Presented with a function typehinted as foo(int $a), the same people who'd
write code in "weak mode" under the current proposal would probably just change
foo($_GET['id']) to foo((int) $_GET['id']), with exactly the same effect. There
is absolutely nothing the author of foo() can do to stop them, no matter what
options we give at the definition site.
The sheer difficulty people are having understanding the "caller is in control"
concept probably counts as its biggest flaw, though...
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
