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

Bug #18117 PEAR coding standard: Method constructor not sniffed as a function
Submitted: 2010-12-15 19:04 UTC
From: dploeger Assigned: squiz
Status: Closed Package: PHP_CodeSniffer (version 1.3.0RC1)
PHP Version: 5.3.3 OS: openSuSE 11
Roadmaps: (Not assigned)    

 [2010-12-15 19:04 UTC] dploeger (Dennis Ploeger)
Description: ------------ In the PEAR coding standard, PEAR/Sniffs/Functions/FunctionCallSignatureSniff.php on line #80, the parsers exits the function code sniffer, because he's creating a new object. But isn't that wrong? Isn't a new object with the embedded call to the constructor also a function call. That way, this is valid: $myNewObj = new NewObj("blablabla long text" . "further long text blablabla" ); A function call, however, prohibits the use of content after the first open bracket... Dennis


 [2010-12-16 04:26 UTC] squiz (Greg Sherwood)
-Assigned To: +Assigned To: squiz
I have no idea why the sniff was coded like that in the first place, but it was obviously deliberate because there are even unit tests to ensure creating new objects is ignored. I'll dig through the history a bit and see if there is any good reason for it. If not, I agree it should be removed and just follow the same rules. The PEAR coding standard doesn't say anything specific about objects as far as I can see.
 [2010-12-16 04:33 UTC] squiz (Greg Sherwood)
Well that didn't take too long to find :) It actually a bug fix for bug #9844 The PEAR error reporting guidelines show that exceptions should be thrown differently to normal function calls. The same code they provide doesn't put any arguments on the first line. All this pre-dates the code changes to support single and multi-line function calls differently in the PEAR standard. With the multi-line function call code now available, this check for the NEW token can be removed.
 [2010-12-16 04:36 UTC] squiz (Greg Sherwood)
-Status: Assigned +Status: Closed
This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on by the end of next Sunday (CET). If this was a problem with the website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.