On Wed, Jun 9, 2010 at 4:17 PM, Zeev Suraski <z...@zend.com> wrote: > At 02:59 09/06/2010, Daniel Convissor wrote: > >> 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 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/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 > > If we introduce the E_TYPE what will be the new default/suggested error level? If it won't be "enabled" by default, then maybe we could introduce this in the whole language. I mean, if you implicitly convert '123asd' to integer, you will trigger this error.
for example: $foo = 0; $foo += (int)'123abc'; // no error $foo += '123abc'; // E_TYPE Tyrael
