With the revived interest in the neighbourhood of type hints in the
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 hintingAt 02:59 09/06/2010, Daniel Convissor wrote:
Hi Lukas:
Same deal as E_NOTICE. Either you care about them or you dont.
Exactly. The type hinting situation is unique. It is something that
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,
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/typecheckingstrictandweakhttp://wiki.php.net/rfc/typecheckingstrictandweakRegarding 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
Hello Zeev
2010/7/29 Zeev Suraski zeev@zend.com:
With the revived interest in the neighbourhood of type hints in the 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
Ill be very much against adding a new error level for typing, E_NOTICE
or E_WARNING should be enough for letting the user know of any data
loss. I don't think it would be a good idea for adding a new error
level for specific language features, if we went to use exceptions for
everything it would however have been a sleek solution but we don't.
As for which solution we should take, we need a userland vote and a
core vote foreach of the 3 solutions we have atm.:
- Strict typehinting (as whats currently in trunk)
- Weak typehinting (with silent autoconvertion)
- Weak typehinting (that emits warnings/notices/type warnings)
It would be nice to have such a vote so the coming RM's also have
control over which solution is preferered and eventually why its
preferered.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hello Zeev
2010/7/29 Zeev Suraski zeev@zend.com:
With the revived interest in the neighbourhood of type hints in the 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
Ill be very much against adding a new error level for typing,
E_NOTICE
orE_WARNINGshould be enough for letting the user know of any data
loss. I don't think it would be a good idea for adding a new error
level for specific language features, if we went to use exceptions for
everything it would however have been a sleek solution but we don't.As for which solution we should take, we need a userland vote and a
core vote foreach of the 3 solutions we have atm.:
- Strict typehinting (as whats currently in trunk)
- Weak typehinting (with silent autoconvertion)
- Weak typehinting (that emits warnings/notices/type warnings)
It would be nice to have such a vote so the coming RM's also have
control over which solution is preferered and eventually why its
preferered.
While on the subject of type-hinting, I propose the idea of a
"callback" type hint, which accepts anything that is callable. This is
useful because it allows a function to be sure a given argument is
callable, and can then safely use it to call a function which requires
a callback, or safely call it using $f(). I think this also falls in
the category of array/Object type hints meaning that it doesn't
present the controversies of strict vs. weak, so I think it could be a
good candidate for inclusion. I made a patch a few weeks back to do
this and can post it if anyone is interested.
Best regards,
--Matthew