Re: Type hinting

On 23 May 2010 07:52, Larry Garfield <larry@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 <mls@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>