last few days I'm resending this email from a few weeks ago.
In a nutshell, use auto-conversion for scalar type hints, and modify
the conversion rules throughout PHP to handle 'senseless' conversions
that result in data loss differently - by emitting E_TYPE.
Zeev
Date: Wed, 9 Jun 2010 17:17:13 +0300
To: Daniel Convissor <danielc@analysisandsolutions.com>
From: Zeev Suraski <zeev@zend.com>
CC: PHP Internals List <internals@lists.php.net>
Subject: Re: [PHP-DEV] Type hinting
I think having E_TYPE (or whatever), a non-fatal notice that can be
either ignored or handled separately from everything else makes
sense. I think we may actually want to introduce it at the most
basic levels of PHP, so that whenever data loss occurs (except for
explicit casts) - an E_TYPE warning will be generated. That will
bring consistency between the new type hinting and the rest of PHP. Thoughts?
Dmitry prepared a patch that implements auto-converting type hinting
with silent data loss. If we combine it with an
infrastructure-level E_TYPE upon data loss - I think we have a
pretty good solution overall. The patch is available at
<http://wiki.php.net/rfc/typecheckingstrictandweak>http://wiki.php.net/rfc/typecheckingstrictandweak
Regarding having an API that allows you to access the original
unconverted value and/or its type - I don't think we should go in
that direction. Presently this information is not retained in any
way, and retaining it would be quite a headache and we'll also incur
a performance penalty. If you're going to be using APIs to
determine what happened to a passed argument and behave accordingly
- why not simply avoid using type hinting, and perform type/value
checks in the function body instead?
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
To: Daniel Convissor <danielc@analysisandsolutions.com>
From: Zeev Suraski <zeev@zend.com>
CC: PHP Internals List <internals@lists.php.net>
Subject: Re: [PHP-DEV] Type hinting
At 02:59 09/06/2010, Daniel Convissor wrote:
Hi Lukas:
applications will frequently want to handle gracefully in order to
provide useful error messages. A new error level is needed, as is an API
/ function to obtain the failed parameter names, desired type and passed
type.
Daniel,Hi Lukas:
On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote:
Same deal as E_NOTICE. Either you care about them or you dont.
Exactly. The type hinting situation is unique. It is something thatSame deal as E_NOTICE. Either you care about them or you dont.
applications will frequently want to handle gracefully in order to
provide useful error messages. A new error level is needed, as is an API
/ function to obtain the failed parameter names, desired type and passed
type.
I think having E_TYPE (or whatever), a non-fatal notice that can be
either ignored or handled separately from everything else makes
sense. I think we may actually want to introduce it at the most
basic levels of PHP, so that whenever data loss occurs (except for
explicit casts) - an E_TYPE warning will be generated. That will
bring consistency between the new type hinting and the rest of PHP. Thoughts?
Dmitry prepared a patch that implements auto-converting type hinting
with silent data loss. If we combine it with an
infrastructure-level E_TYPE upon data loss - I think we have a
pretty good solution overall. The patch is available at
<http://wiki.php.net/rfc/typecheckingstrictandweak>http://wiki.php.net/rfc/typecheckingstrictandweak
Regarding having an API that allows you to access the original
unconverted value and/or its type - I don't think we should go in
that direction. Presently this information is not retained in any
way, and retaining it would be quite a headache and we'll also incur
a performance penalty. If you're going to be using APIs to
determine what happened to a passed argument and behave accordingly
- why not simply avoid using type hinting, and perform type/value
checks in the function body instead?
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
