FAQ
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 <danielc@analysisandsolutions.com>
From: Zeev Suraski <zeev@zend.com>
CC: PHP Internals List <internals@lists.php.net>
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


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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Search Discussions

  • Kalle Sommer Nielsen at Jul 29, 2010 at 3:19 pm
    Hello Zeev

    2010/7/29 Zeev Suraski <zeev@zend.com>:
    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
  • Matthew Fonda at Jul 29, 2010 at 7:02 pm

    On Thu, Jul 29, 2010 at 8:18 AM, Kalle Sommer Nielsen wrote:
    Hello Zeev

    2010/7/29 Zeev Suraski <zeev@zend.com>:
    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.
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJul 29, '10 at 12:18p
activeJul 29, '10 at 7:02p
posts3
users3
websitephp.net

People

Translate

site design / logo © 2022 Grokbase