On 02/01/2015 10:54, Markus Fischer wrote:
On 02.01.15 05:36, Levi Morrison wrote:
I don't necessarily have any more insight to provide than has already
been done, but I do want to chime in and say that I personally favor
strict types as Nikita Popov has been advocating.
Same from me. I support all arguments so far made by Nikita; they're
well laid out, better than I could have done it.
And I, on the other hand, disagree.
Looking at it from an OSS maintainer perspective, introducing strict
hints in code would be a huge BC break as I don't know how people use my
code, nor if they validate/coerce their user input early or not. If I
suddenly declare something as int and someone used to pass '5', they get
an error. That would make adoption quite hard in OSS IMO if you don't
want to bother people.
With weak typing on the other hand, I get to remove tons of @param
annotations which would be amazing, and I get additional safeties that
*new* mis-uses (like passing an object in an arg expecting a string,
which at the moment could not be type hinted) will be caught early in
the future.
Existing mis-uses probably don't exist much since they'd likely fail
further down in the code execution already, but in case they don't
they'd be caught too and that's a good thing since it makes people look
at their buggy code.
As for valid uses of the code, like the '5' above, it keeps working just
fine because it is fine. It's not my call as a library author to decide
whether the users of the lib should cast user inputs to ints or validate
them or do nothing at all.
Besides, IMO if strict typing was so desirable we would see more of the
String/Int classes out there, or we would see people do things like:
function foo($number, $string) {
expectNumber($number); expectString($string);
}
That'd be a simple lib to write, it barely adds more code to your
functions, and you get strict typing. But I hardly see anyone do this,
and I would argue it's because it sounds appealing in theory but it's
not worth it in practice.
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
