Hello Mike,
> On 15 Jan 2015, at 16:55, Mike Willbanks <pen...@gmail.com> wrote:
>
> I actually quite disagree with that statement.
I don’t understand. I said "either approach to scalar hints will upset a large
portion of the community”. Are you not demonstrating that point, in that you
don’t like the strict approach?
> Both as a library/framework developer and a user land developer I find
> strict typing to be more of an issue. For instance:
>
> function foo(int $foo)
> foo('23');
>
> This would be a pain and cause constant glue from userland:
> Option A: Force Cast aka (int) '23'
> Option B: Check for digits via ctype_digits then force cast
> etc.
>
> To provide more of a point here, variables coming from HTTP are always a
> string, this makes strict casting a troubling item, considering that the main
> way of fetching input is coming from the web specifically. I'm certain this
> would also affect other areas as well such as reading csv files and more. To
> me this point alone makes a vastly strong statement against strict typing and
> as such, it would make life far more difficult for library developers and
> user land developers alike.
Well, this RFC doesn’t force you to use strict type checking. Quite the
opposite.
> I agree with the others in that declarative syntax to change it is a bad
> idea. It actually reminds me of ECMAScript 5's "use strict"
> (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode)
> condition. Changing the definition based on user land scripts can lead to
> bugs and inconsistencies in a library developers purpose of a package and
> cause bad conditions. It also means that then a library developer would need
> to handle conditions on both sides (when in weak vs. strict).
No, the library developer would never need to “handle both cases”. Your library
always gets the type it asks for. The RFC is quite clear on this. Your code
will always behave exactly the same.
Thanks.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
