> -----Original Message----- > From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Sunday, September 14, 2014 3:08 PM > To: Stas Malyshev > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast > > > The problem is that we *can't* be consistent. Internal functions already live in > this completely different world from user land functions. Nullability is handled > differently. They use implicit casts in places as if they were user land functions > with no parameter types at all. In other places they have strongly typed > parameters. If they are passed invalid data, they usually just return NULL and > emit a warning, though this depends on the function. User land functions, by > contrast, will emit a recoverable error if the wrong type is passed. To make > these two consistent would require massive backwards-compatibility breaks.
I honestly don't see why we can't be consistent for the simple types, or at least strive to be as consistent as possible as opposed to introducing a complete parallel universe for userland functions, that's inconsistent with the entirety of the rest of PHP. We don't have to be consistent with ALL internal functions, which obviously have the option of doing custom checks and return failures not only if you fail to, say, pass on a string - but also if that string is not of a special format. But then, you have the option of doing that also in userland functions using custom code. The question is not the customized cases - it's the standard behavioral cases - comparing zpp rules for scalars and the newly-introduced rules for userland scalars. We could definitely strive to be consistent; Introduce some changes to the implicit casting rules for internal functions and implement the very same rules for this brand new userland functions. I'm definitely against this RFC in its current form. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
