RE: [PHP-DEV] Type hinting
| From: | Jared Williams | Date: | Wed, 09 Jun 2010 16:55:39 +0000 |
| Subject: | RE: [PHP-DEV] Type hinting | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-48710@lists.php.net to get a copy of this message | ||
> -----Original Message-----
> From: Zeev Suraski [mailto:zeev@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