# Fwd: Re: Type hinting - Thread: https://externals.io/message/49171 - Original archive: https://news-web.php.net/php.internals/49171 - Started by Zeev Suraski on 2010-07-29T12:17:57+00:00 - Messages: 3 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #49171 — Zeev Suraski — 2010-07-29T12:17:57+00:00 URL: https://externals.io/message/49171#49171 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 >From: Zeev Suraski >CC: PHP Internals List >Subject: Re: [PHP-DEV] Type hinting > >At 02:59 09/06/2010, Daniel Convissor wrote: > > […] > >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/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 --- ## #49172 — Kalle Sommer Nielsen — 2010-07-29T15:18:59+00:00 URL: https://externals.io/message/49171#49172 · In reply to: #49171 Hello Zeev 2010/7/29 Zeev Suraski : > 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 --- ## #49174 — Matthew Fonda — 2010-07-29T19:02:21+00:00 URL: https://externals.io/message/49171#49174 · In reply to: #49172 > > Hello Zeev > > 2010/7/29 Zeev Suraski : > > […] > > 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. 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