Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.5.0a1

Bug #16279 Type Hints in Function Signature Cause Loss of @param type
Submitted: 2009-06-02 19:18 UTC
From: ashnazg Assigned: ashnazg
Status: Closed Package: PhpDocumentor (version 1.4.0)
PHP Version: 5.2.4 OS: RHEL4
Roadmaps: 1.4.4    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 46 - 8 = ?

 
 [2009-06-02 19:18 UTC] ashnazg (Chuck Burgess)
Description: ------------ Having type hints for arguments in the code's function signature results in phpDocumentor *losing* the datatype given in the @param tag. The tag's datatype is still visible in the parameter listing of the generated docs, but the datatype is not included in the doc's function signature This was reported on SourceForge Help forum (http://sourceforge.net/forum/message.php?msg_id=7385645) Test script: --------------- <?php /** * test class */ class Foo { /** * @param array $a an array that does something */ public function bar (array $a) {} } ?> Expected result: ---------------- foo (array $a) * array $a: an array that does something Actual result: -------------- foo ( $a) * array $a: an array that does something

Comments

 [2009-06-02 19:18 UTC] ashnazg (Chuck Burgess)
-Status: Open +Status: Verified -Package Version: 1.4.2 +Package Version: 1.4.0
I duplicated this behavior using v1.4.0 on PHP v5.2.4 on RHEL4.
 [2009-10-12 02:02 UTC] ashnazg (Chuck Burgess)
-Assigned To: +Assigned To: ashnazg -Roadmap Versions: +Roadmap Versions: 1.4.4
 [2009-10-12 09:51 UTC] ashnazg (Chuck Burgess)
Issue seems to be in ParserElements.inc, in parserFunction::getIntricateFunctionCall(). Whenever a type hint has already been set (in $param[2]), it calls out to Converter::getLink() to determine if it's a datatype that is actually an element in the code. If nothing is found, getLink() just returns the original string. The logic then only looked for a non-false value before overwriting the stored datatype with getLink()'s return value (in this case, 'object int'). This ultimately resulted in the 'int' datatype being overwritten with 'false' that was later returned by Converter::returnSee(). I modified the logic to check for a non-false return of getLink(), and then verify that the return value was *not* the exact same string it was given to start with... in other words, if getLink() doesn't return an actual link string (that should differ from the original arg), then we don't really have a link, and therefore let's keep the original datatype value that's in $param[2]. This solves the test case file for all output converters I tried. As an additional verification, I changed the test file to : class Foo { /** * @param array $a an array that keeps its type hint * @param int $b an integer that loses its type hint * @param Foo $c another Foo object */ public function bar ($a, int $b, Foo $c) {} } just to be sure that the Foo datatype became a link to the Foo class in the docs, in both its appearance in the tag listing and the function signatures.
 [2009-10-12 09:52 UTC] ashnazg (Chuck Burgess)
-Status: Verified +Status: Closed