Hello Jordi,
On 02.01.2015 15:01, Jordi Boggiano wrote:
> 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.
I'd argue if your concern is so big, you just wouldn't do it ... it's up
to the author how he sees it fit and wants to use it. You could make all
your public facing methods don't use them but only use it internally
(aha, just saw someone mentioned this in another email too; weird).
> With weak typing on the other hand, I get to remove tons of @param
> annotations which would be amazing
[...]
I hope you don't because @param should also be describing the
purpose/usage of the parameter ;-)
> 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.
That's really interesting, because I as library author actually do
provide "how to use my library". I mean:
- I create it with my vision
- I document it
- I create the examples how to use it
- I decide what's private/protected/public, i.e. how extensible things are
Well, there's lot of "I" but that would also apply to teams and their
decision how to use it.
My want-to-be-on-the-safe-side-code currently is either riddled with
explicit casts or simple nothing; I try to keep my methods small and
that overhead could outweigh code logic sometimes which I'd consider
counterproductive.
>
> 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:
Well, performance; manual boxing/unboxing is IMHO not really feasible to
do with the interpreter currently (ok; gut feeling here, no benchmark).
So, yes, I would use it if the overall overhead incurred would IMHO just
not make it feasible. (sorry for repeating)
>
> 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.
I'd love to to that but simply also don't want to clutter my code with
such an approach.
The current situation to me is a bit like: it bothers me, but not to the
point I'd clutter my code with an approach like you've shown (and was
tempted multiple times in the past to do ...)
Although it seems like I wrote so many "counter" argument, please don't
misinterpret. For the love of history I merely told my view and I'm
actually glad you shared yours; with this important topic for PHP,
however it ends, there can't be too many views on that matter.
thank you,
- Markus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
