Ilia Alshanetsky wrote:
On 2-Jul-09, at 9:23 AM, Robert Cummings wrote:
Ilia Alshanetsky wrote:
On 2-Jul-09, at 9:04 AM, Robert Cummings wrote:
Ilia Alshanetsky wrote:
Paul's proposal is some part does not make sense because it
allows weak type hinting, which should not be used if you need
type hinting. The whole idea about type hinting is definition
of strict interfaces, not loosely based one. That's just my
opinion, which admittedly I feel fairly strongly about.
It's a hint, not enforcement. IMHO hinting about something is not
strict, it's a suggestion.
Have you using existing array or class type hinting?
I have, and IMHO it makes more sense for strict checking (though not
too strict since super classes make sense) when objects are being
passed. But in the case of primitive datatypes where coercion
between types is well established and understood, I think it should
be a warning. PHP knows how to convert the string '1' to integer. It
knows how to convert 0 to boolean false. These were established many
years ago. On the other hand PHP does not know how to coerce (in a
sensible way) class FreakyDeaky to class GobbletyGoot.
It is not about what PHP can convert, in the past and if you use old
function parameter parsing api PHP will even convert arrays to
strings. Its about delivering to the function/method exactly what it
wants and not a close facsimile thereof.
That's why I said, instead of E_RECOVERABLE it should be an E_WARNING
with type coercion to what the hint requested. The function gets what it
wants, and the developer gets a warning that it wasn't quite what it
expected. Run time code doesn't just die because I've upgraded an
application and missed a single API call update to comply with primitive
type hinting. That's annoying in a production environment, and since
it's run-time fail, it's not necessarily easy to catch all the issues.
There *will* be production systems dying due to missed updates.
There's the suggestion to capture the E_RECOVERABLE error, but that's
putting the onus on developers and non-developers installing
applications to have this in place, and due to the run-time nature of
the problem, *everyone* would be better off putting it in place, just in
case their production system goes down. Since 99% of coercions of
primitive types are fine, I don't see why the majority must suffer the
problem when the minority will be perfectly served by an E_WARNING to
correct their code. You mentioned in your environment you've been using
this for a while now and found problems otherwise very difficult to
find. These same problems would also have been detected with an
E_WARNING with the added value of the application not dying (or do you
already have that E_RECOVERABLE handler in place).
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
