> -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Thursday, February 26, 2015 9:29 PM > To: Mike Willbanks > Cc: Dan Ackroyd; Zeev Suraski; Theodore Brown; internals@lists.php.net > Subject: Re: [PHP-DEV] A different user perspective on scalar type > declarations > > Mike, > > One point of clarification: > > > This is true, however, the types that you are receiving back form a > > multitude of data sources might be in a mixed format (databases for > > example often provide representation back as a string, non-json based > > web > services > > provide mainly as a string, etc). While I know what my data looks like > > and I know I am always going to get a "string" integer back I do not > > want to have to type cast this each and every time. Or that I have a > boolean > > integer representation that is in a string... You get the point. Sure, > > I > > could certainly go in and take 5 minutes and cast each one but I'm not > > certain why the purpose is there... It specifically changes the > > determination that PHP is a weakly typed language and all of a sudden > > I now need to care that my string integer boolean is not actually a > > boolean. > > It's funny that you bring up boolean... > > With the current coercive proposal, you will still need to worry about the > types: https://wiki.php.net/rfc/coercive_sth#coercion_rules
That's true, but a lot, lot less. > Passing boolean(false) where an integer is expected will generate an > error. > This is a common practice, specifically around internal functions. > Example: > https://github.com/sebastianbergmann/phpunit/blob/a4e23a10d4eeea5fd9f > e8916859a07430b94cf42/src/Util/ErrorHandler.php#L58 It's actually not nearly as common as one might think, and arguably - it's may be hiding bug or at least some misunderstanding about the semantics of the argument (not always, but sometimes). Warning about it (as deprecated) makes perfect sense. I'm going to send some data from real world apps later today or early tomorrow. Spoiler - not a lot of breakage at all, and coercive rules seem to have a remarkably good signal to noise ratio. > The difference is with the dual-mode RFC you can choose not to have to > cast > and keep everything as-is today (or more specifically, you need to > explicitly > choose strict mode). And you can have user-land behave identically to > internals **in both cases**. Put another way, coercive gets to keep a single, sensible conversion rule-set in PHP - with relatively minor updates needed over the course of several years. And contrary to what might be implied here, it would require a LOT less casting - while still taking advantage of much better data sanitation. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
