> -----Original Message----- > From: Zeev Suraski [mailto:z...@zend.com] > Sent: 09 June 2010 15:17 > To: Daniel Convissor > Cc: PHP Internals List > Subject: Re: [PHP-DEV] Type hinting > > 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 >
Is E_TYPE good enough? If it follows the other E_*, I'd suggest it's not. Just having a single string error message describing the error, and having to unmangle the detailed information* from that doesn't seem that great. * Which parameter, what value, what was expected. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
