On 23 May 2010 07:52, Larry Garfield <la...@garfieldtech.com> wrote:
> On Saturday 22 May 2010 11:43:50 pm Zeev Suraski wrote:
>> At 01:01 23/05/2010, Hannes Magnusson wrote:
>> >On Sat, May 22, 2010 at 22:39, Lukas Kahwe Smith <m...@pooteeweet.org>
> wrote:
>> > > On 22.05.2010, at 18:30, Josh Davis wrote:
>> > >> As you wrote, you worked on PHP's _type system_ which is dynamic,
>> > >> really cool, juggles strings with ints and what not. However, the
>> > >> topic here is the _type hinting system_. As far as I know, there's no
>> > >> "weak" type hinting; if a method signature hints for an array and is
>> > >> given an integer, it throws a catchable fatal error. Therefore, as a
>> > >> user, what I am familiar to is a strict _type hinting system_.
>> > >> Anything else would feel inconsistent to me.
>> >
>> >I agree. function foo(array $x) {} foo(123); doesn't cast int(123) to
>> >array(123) so introducing different meaning for scalar types feels
>> >very very wrong.
>>
>> You're ignoring one simple fact - in PHP, scalar types are
>> interchangeable. Unlike array->scalar which has always been a corner
>> case and a sketchy one (and I said numerous times that had I rewrote
>> the language now, array->scalar conversion would have probably
>> resulted in an error) - string->number, number->string,
>> string->boolean conversions are a cornerstone of the language. If
>> you don't like the fact that PHP's scalar types are interchangeable -
>> you're in the wrong language!
>>
>> In terms of consistency, the difference between array type hinting
>> and scalar type hinting you allude to is negligible in comparison to
>> the inconsistency with, well, just about every other part of the
>> language - operators, control structures and built-in functions
>> (expecting sqrt("64") to fail, since sqrt() expects a
>> number? expecting if (7) to fail, since it expects a
>> boolean?). Auto-converting type hinting extends the same semantics
>> available to internal functions (through zend_parse_parameters()) to
>> userland functions. That consistency is by far the most important IMHO.
>>
>> Zeev
>
> I have to largely agree with Zeev here. I'm not an internals developer but I
> do write a lot of widely used framework-ish open source PHP.
>
> The current OO type specifying system I have always mentally viewed, and most
> people I know seem to view it, as a check not for "is this an X", but "can I
> treat this as X without things exploding"? In the context of an object,
> "exploding" would mean a "method not found" fatal. In the context of an
> array, it would be the dreaded "parameter 1 to foreach() is not an array".
> The idea is two fold: One, better documentation (especially for code
> assistance IDEs), and two, if it's going to explode it should explode in a way
> that's useful in terms of where it exploded. (Vis, the error message is on a
> useful line and tells me what the actual problem was.)
>
> For scalar types, exploding would mean "loss of precision". There is no loss
> of precision in converting "5" to int(5), so that doesn't explode, nor should
> it. There is similarly no loss of precision converting from int(5) to
> float(5), so that also shouldn't explode. "123abc" does have a loss of
> precision (data would get lost in the conversion) so that should fail both int
> and float checks.
>
> If anything, I'd be even more forgiving than the table in Zeev and Lukas' RFP.
> float(12) converting to an int doesn't have any precision loss so I don't
> think
> that should fail.
>
> The RFP includes a variety of good reasons why a more naive strict check is
> inconsistent to the point of making it a bug rather than a feature. One in
> particular I want to call out: Everything that comes back from a database does
> so as a string. To wit:
>
> table users(user_id, name, pass, blah);
>
> $user_id = $pdo->query("SELECT user_id FROM users WHERE name='bob' AND
> pass='foo'")->fetchColumn();
>
>
> doStuff($user_id);
>
> function doStuff(int $user_id) {
> // Whatever.
> }
>
>
> The above code will fail with the current implementation, even though we know
> for a fact that user_id is integer data because that column is an int in the
> database itself. Requiring an extra blind (int) stuffed in there is
> pointless,
> and if anything just trains people to blindly cast data without thinking about
> what it really is. I can see that introducing more bugs than it avoids.
>
> --Larry Garfield
>
+1
Regards
Peter
--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
</hype>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
