Andrey Andreev wrote on 16/01/2015 13:00:
Hi,
On Fri, Jan 16, 2015 at 2:29 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
Mike Willbanks wrote on 15/01/2015 16:55:
It also means that then a library developer would
need to handle conditions on both sides (when in weak vs. strict). So I
don't really understand where the gains of this would come from and it
actually causes me concern in that what if a developer forgets to define
strict and you're entire system is built on strict.
In case this hasn't been repeated enough times already: No They Would Not.
As a library developer, you do not rely on strict or weak hints, you rely on
the variables you receive being of the types you require. This is guaranteed
in both modes.
You cannot stop the user of your library doing whatever it takes to get past
your validation. It is up to them to provide sane inputs to your published
API, and no version of type hinting can change that.
This is mostly true, but relying on the variable that you receive
inside a function is different from relying on the variable that gets
passed to a function.
Yes, there will be users who will simply do an explicit cast, but
there will also be users who will take notice of the produced error,
and ask themselves why first, instead of immediately trying to
"override" it.
Many developers want to do that, regardless of the reasons why. Some
just like the strict philosophy better, some see it as a way of
educating their users, and others use it sparingly. Try arguing with
anybody writing crypto code and they will all tell you that any case
of uncertainty must be handled with a *hard* failure.
You may not agree that it is necessary, but that doesn't make it
invalid. And intentionally allowing only one guaranteed behavior does
imply that the other is invalid.
For the Nth time - if I want to achieve that effect, I will code for
both cases by not using the feature and doing is_int(), is_string(),
is_bool(), etc. checks, so the language might as well help me do it. I
would understand if it was not helping with something that's just
wrong, but this is not the case at all here.
OK, point taken. I do think that it's a bad idea for library authors to
do that, so don't think the language should make it easy, but I
understand that some people want to do it.
Specifically, I don't think a library author should be able to tell me
that, just because they're feeling picky, '42' and 42 are not equivalent
when calling their function. It does very little to protect me from
genuine mistakes (passing completely the wrong parameter), and makes my
life as user of the library harder.
But then, fundamentally, that's the argument against having strict
typing full stop, and it's painfully clear that there's a big divide of
opinion on that.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
