FAQ
Pretty straight-forward. Makes it easier to recreate a function
signature from PHP (Mocking)
https://wiki.php.net/rfc/reflectionparameter.typehint

Search Discussions

  • Andrea Faulds at May 29, 2014 at 8:51 pm

    On 29 May 2014, at 20:59, Sara Golemon wrote:

    Pretty straight-forward. Makes it easier to recreate a function
    signature from PHP (Mocking)
    https://wiki.php.net/rfc/reflectionparameter.typehint
    Why 5.7? Looks like the sort of self-contained function addition you could get into 5.6.1.
    --
    Andrea Faulds
    http://ajf.me/
  • Levi Morrison at May 29, 2014 at 8:53 pm

    On Thu, May 29, 2014 at 2:51 PM, Andrea Faulds wrote:
    On 29 May 2014, at 20:59, Sara Golemon wrote:

    Pretty straight-forward. Makes it easier to recreate a function
    signature from PHP (Mocking)
    https://wiki.php.net/rfc/reflectionparameter.typehint
    Why 5.7? Looks like the sort of self-contained function addition you could get into 5.6.1.
    Personally I think we shouldn't add features in 5.6.1. Those should be
    reserved for bug and security fixes.
  • Sara Golemon at May 29, 2014 at 9:55 pm

    On Thu, May 29, 2014 at 1:53 PM, Levi Morrison wrote:
    On Thu, May 29, 2014 at 2:51 PM, Andrea Faulds wrote:
    On 29 May 2014, at 20:59, Sara Golemon wrote:
    Pretty straight-forward. Makes it easier to recreate a function
    signature from PHP (Mocking)
    https://wiki.php.net/rfc/reflectionparameter.typehint
    Why 5.7? Looks like the sort of self-contained function addition you could get into 5.6.1.
    Personally I think we shouldn't add features in 5.6.1. Those should be
    reserved for bug and security fixes.
    Agreed. Point releases have traditionally been for bugfixes only.
    Sometimes we sneak new functionality in, but there's not enough of an
    urgent, earth-shattering need for these functions to justify it. With
    our pace of yearly releases and the fact that 5.6 is already in alpha,
    it makes sense to me to be conservative and only add to 5.next.

    -Sara
  • Levi Morrison at May 29, 2014 at 8:55 pm

    On Thu, May 29, 2014 at 1:59 PM, Sara Golemon wrote:
    Pretty straight-forward. Makes it easier to recreate a function
    signature from PHP (Mocking)
    https://wiki.php.net/rfc/reflectionparameter.typehint
    Sara,

    I'm hoping to improve the way types are handled in reflection but I've
    been waiting until the return types and nullable types RFCs have been
    voted on as that will most likely impact my decisions. I'd like to
    introduce getType and hasType functions that holds various bits of
    information such as isArray(), isCallable() and could also contain the
    text representation of the type. What are your thoughts on that?
  • Sara Golemon at May 29, 2014 at 10:01 pm

    On Thu, May 29, 2014 at 1:55 PM, Levi Morrison wrote:
    On Thu, May 29, 2014 at 1:59 PM, Sara Golemon wrote:
    Pretty straight-forward. Makes it easier to recreate a function
    signature from PHP (Mocking)
    https://wiki.php.net/rfc/reflectionparameter.typehint
    I'm hoping to improve the way types are handled in reflection but I've
    been waiting until the return types and nullable types RFCs have been
    voted on as that will most likely impact my decisions. I'd like to
    introduce getType and hasType functions that holds various bits of
    information such as isArray(), isCallable() and could also contain the
    text representation of the type. What are your thoughts on that?
    As in something like this?

    $rf = new ReflectionFunction('foo');
    list($rp) = $rf->getParameters();
    $hint = $rp->getType(); // returns ReflectionTypeHint
    if ($hint->isArray()) { ... }

    I thought about that (and would like to see it), which is why I
    specifically went for the name getTypehintText(), which leaves the
    "get me an object version" (i.e. getTypehint()) left available. See
    also: https://wiki.php.net/rfc/reflectionparameter.typehint#on_the_naming
      If you think it's a bit too busy to have getTypehint(): object, and
    getTypehintText(): string, I can hold off on this RFC for awhile.
    There's certainly no rush.


    Or did you mean something else?

    -Sara
  • Levi Morrison at May 29, 2014 at 10:22 pm

    On Thu, May 29, 2014 at 4:01 PM, Sara Golemon wrote:
    On Thu, May 29, 2014 at 1:55 PM, Levi Morrison wrote:
    On Thu, May 29, 2014 at 1:59 PM, Sara Golemon wrote:
    Pretty straight-forward. Makes it easier to recreate a function
    signature from PHP (Mocking)
    https://wiki.php.net/rfc/reflectionparameter.typehint
    I'm hoping to improve the way types are handled in reflection but I've
    been waiting until the return types and nullable types RFCs have been
    voted on as that will most likely impact my decisions. I'd like to
    introduce getType and hasType functions that holds various bits of
    information such as isArray(), isCallable() and could also contain the
    text representation of the type. What are your thoughts on that?
    As in something like this?

    $rf = new ReflectionFunction('foo');
    list($rp) = $rf->getParameters();
    $hint = $rp->getType(); // returns ReflectionTypeHint
    if ($hint->isArray()) { ... }

    I thought about that (and would like to see it), which is why I
    specifically went for the name getTypehintText(), which leaves the
    "get me an object version" (i.e. getTypehint()) left available. See
    also: https://wiki.php.net/rfc/reflectionparameter.typehint#on_the_naming
    If you think it's a bit too busy to have getTypehint(): object, and
    getTypehintText(): string, I can hold off on this RFC for awhile.
    There's certainly no rush.
    Yeah, I mean something like that. Maybe we could collaborate in IRC
    somewhere to work out details? We can move much faster that way. I'm
    regularly in #hhvm on freenode and #php.doc and #php.pecl on efnet as
    LeviM or LeviM_t.
  • Sara Golemon at May 30, 2014 at 12:44 am

    On Thu, May 29, 2014 at 3:22 PM, Levi Morrison wrote:
    On Thu, May 29, 2014 at 4:01 PM, Sara Golemon wrote:
    $rf = new ReflectionFunction('foo');
    list($rp) = $rf->getParameters();
    $hint = $rp->getType(); // returns ReflectionTypeHint
    if ($hint->isArray()) { ... }

    I thought about that (and would like to see it), which is why I
    specifically went for the name getTypehintText(), which leaves the
    "get me an object version" (i.e. getTypehint()) left available. See
    also: https://wiki.php.net/rfc/reflectionparameter.typehint#on_the_naming
    If you think it's a bit too busy to have getTypehint(): object, and
    getTypehintText(): string, I can hold off on this RFC for awhile.
    There's certainly no rush.
    Yeah, I mean something like that. Maybe we could collaborate in IRC
    somewhere to work out details? We can move much faster that way. I'm
    regularly in #hhvm on freenode and #php.doc and #php.pecl on efnet as
    LeviM or LeviM_t.
    Per our conversation in IRC, I've updated the RFC and implementation
  • Derick Rethans at May 29, 2014 at 10:54 pm

    On Thu, 29 May 2014, Sara Golemon wrote:

    Pretty straight-forward. Makes it easier to recreate a function
    signature from PHP (Mocking)
    https://wiki.php.net/rfc/reflectionparameter.typehint
    I don't think it should return an empty string when hasTypehint has
    failed (the 4th "test") in your test case (for $d). IMO, it should
    return NULL.

    cheers,
    Derick
  • Levi Morrison at May 30, 2014 at 1:08 am

    On Thu, May 29, 2014 at 4:54 PM, Derick Rethans wrote:
    On Thu, 29 May 2014, Sara Golemon wrote:

    Pretty straight-forward. Makes it easier to recreate a function
    signature from PHP (Mocking)
    https://wiki.php.net/rfc/reflectionparameter.typehint
    I don't think it should return an empty string when hasTypehint has
    failed (the 4th "test") in your test case (for $d). IMO, it should
    return NULL.
    If it doesn't have type information I think an empty string should be
    returned. Since you can't have an empty type hint there really isn't a
    conflict there. This means the function can always return a string.

    That's my $0.02.
  • Adam Harvey at May 30, 2014 at 5:06 am

    On 29 May 2014 18:08, Levi Morrison wrote:
    On Thu, May 29, 2014 at 4:54 PM, Derick Rethans wrote:
    I don't think it should return an empty string when hasTypehint has
    failed (the 4th "test") in your test case (for $d). IMO, it should
    return NULL.
    If it doesn't have type information I think an empty string should be
    returned. Since you can't have an empty type hint there really isn't a
    conflict there. This means the function can always return a string.
    I'd prefer NULL to indicate the complete absence of a type hint too —
    it ends up as an empty string if it's used in that context regardless,
    but the changed type is useful. I don't feel strongly enough about
    this that it would affect my vote, though.
    That's my $0.02.
    Adam, providing 2.17 Canadian cents.
  • Sara Golemon at May 30, 2014 at 6:50 pm

    On Thu, May 29, 2014 at 10:06 PM, Adam Harvey wrote:
    I'd prefer NULL to indicate the complete absence of a type hint too —
    it ends up as an empty string if it's used in that context regardless,
    but the changed type is useful. I don't feel strongly enough about
    this that it would affect my vote, though.
    The current version of the RFC makes this point moot.

    hasTypeAnnotation() would return false, while
    getTypeAnnotation() would return NULL (as opposed to a
    ReflectionTypeAnnotation instance)

    The new equivalent to $rp->getTypehintText() is now
    (string)$rp->getTypeAnnotation()

    -Sara
  • Levi Morrison at Jun 2, 2014 at 12:38 am
    We might want to rename `ReflectionTypeAnnotation::isNullable` to
    `ReflectionTypeAnnotation::allowsNull`. I think it is a bit more
    understandable; it also is used by `ReflectionParmeter` so it would be
    a bit more consistent. What do you think?
  • Sara Golemon at Jun 2, 2014 at 3:33 pm

    On Sun, Jun 1, 2014 at 5:38 PM, Levi Morrison wrote:
    We might want to rename `ReflectionTypeAnnotation::isNullable` to
    `ReflectionTypeAnnotation::allowsNull`. I think it is a bit more
    understandable; it also is used by `ReflectionParmeter` so it would be
    a bit more consistent. What do you think?
    Absent pre-existing uses, I like following the is*() pattern of
    isArray/isCallable for consistency. But good catch, it's probably
    best to avoid inconsistency with the parent class.

    -Sara
  • Derick Rethans at Jun 9, 2014 at 2:47 pm

    On Thu, 29 May 2014, Sara Golemon wrote:

    Pretty straight-forward. Makes it easier to recreate a function
    signature from PHP (Mocking)
    https://wiki.php.net/rfc/reflectionparameter.typehint
    On your updated proposal, there is a comment on how class names should
    be returned. Right now, the test case only tests for "StdClass", but I
    also think you should have a look at namespaced classes, and full
    qualified class names in tests. I think that might show class names
    should be returned with a \ in front of it.

    cheers,
    Derick

    --
    http://derickrethans.nl | http://xdebug.org
    Like Xdebug? Consider a donation: http://xdebug.org/donate.php
    twitter: @derickr and @xdebug
    Posted with an email client that doesn't mangle email: alpine
  • Sara Golemon at Jun 10, 2014 at 5:45 pm

    On Mon, Jun 9, 2014 at 7:47 AM, Derick Rethans wrote:
    On Thu, 29 May 2014, Sara Golemon wrote:
    Pretty straight-forward. Makes it easier to recreate a function
    signature from PHP (Mocking)
    https://wiki.php.net/rfc/reflectionparameter.typehint
    On your updated proposal, there is a comment on how class names should
    be returned. Right now, the test case only tests for "StdClass", but I
    also think you should have a look at namespaced classes, and full
    qualified class names in tests. I think that might show class names
    should be returned with a \ in front of it.
    Nice catch, I'll integrate that after Levi has finished with his
    return type hinting rfc (we agreed to get his bit done first, then
    I'll rebase my reflection stuff onto it)

    -Sara

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 29, '14 at 7:59p
activeJun 10, '14 at 5:45p
posts16
users6
websitephp.net

People

Translate

site design / logo © 2022 Grokbase