Re: Type hinting
| From: | Ferenc Kovacs | Date: | Wed, 09 Jun 2010 14:54:29 +0000 |
| Subject: | Re: Type hinting | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-48708@lists.php.net to get a copy of this message | ||
On Wed, Jun 9, 2010 at 4:17 PM, Zeev Suraski <zeev@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