php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #52909 ReflectionMethod::getParameters() return incorrect number of arguments
Submitted: 2010-09-22 23:17 UTC Modified: 2018-08-05 01:49 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: frederic dot hardy at mageekbox dot net Assigned: carusogabriel (profile)
Status: Closed Package: PHAR related
PHP Version: 5.3.3 OS: FreeBSD 8.0
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: frederic dot hardy at mageekbox dot net
New email:
PHP Version: OS:

 

 [2010-09-22 23:17 UTC] frederic dot hardy at mageekbox dot net 
Description:
------------
I'm using PHP 5.3.3 and PHP trunk under FreeBSD 8.0 p4.
I'm trying to retrieve arguments of phar::__construct() with ReflectionMethod::getArguments().
Phar::__construct() take only 3 arguments, but my script return 4 arguments, as if PharData::__construct() was used instead of Phar::__construct() by the reflection API.
In fact, ext/phar_object.c contains the following comments :
/* {{{ proto void Phar::__construct(string fname [, int flags [, string alias]])
 * Construct a Phar archive object
 * {{{ proto void PharData::__construct(string fname [[, int flags [, string alias]], int file format = Phar::TAR])
 * Construct a PharData archive object
 */
PHP_METHOD(Phar, __construct)
{
...
}

Test script:
---------------
<?php

$method = new reflectionMethod('phar', '__construct');


foreach ($method->getParameters() as $parameter)
{
	var_dump($parameter->getName());
	var_dump($parameter->isOptional());
	var_dump($parameter->isDefaultValueAvailable());
}

?>


Expected result:
----------------
string(8) "filename"
bool(false)
bool(false)
string(5) "flags"
bool(true)
bool(false)
string(5) "alias"
bool(true)
bool(false)


Actual result:
--------------
string(8) "filename"
bool(false)
bool(false)
string(5) "flags"
bool(true)
bool(false)
string(5) "alias"
bool(true)
bool(false)
string(10) "fileformat"
bool(true)
bool(false)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-09-22 23:44 UTC] tony2001@php.net
-Type: Bug +Type: Documentation Problem
 [2010-09-22 23:44 UTC] tony2001@php.net 
The docs and the comment in the sources are apparently wrong and need fixing.
 [2010-09-23 06:27 UTC] aharvey@php.net
-Status: Open +Status: Assigned -Package: Reflection related +Package: PHAR related -Assigned To: +Assigned To: aharvey
 [2010-09-23 06:39 UTC] aharvey@php.net 
The reason for this is that Phar and PharData actually use the same function for their __construct implementations -- internally it calls instanceof_function() to figure out whether it's constructing a Phar or PharData object and then has some if statements to handle things from there. There's no distinct arginfo for the PharData implementation, so reflection has no way of distinguishing the three parameter Phar constructor from the four parameter PharData constructor.

I'll make the proto comment in phar_object.c a little clearer (and remove the extra vim fold that doesn't do anything useful). Beyond that, the manual's correct for Phar::__construct() but not for PharData::__construct() (which is currently documented as accepted two parameters when it actually accepts four), so I'll fix that up.

I don't see any way of getting reflection to do the right thing short of refactoring the function into two -- which might be the right thing to do anyway, but is a decision for Greg or Marcus to make.
 [2010-09-23 06:41 UTC] aharvey@php.net 
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=303709
Log: Fix up the vim folds in phar_object.c and add a note that the two prototypes
before Phar::__construct() are actually valid and not a mistake, per bug
#52909.
 [2010-09-23 06:52 UTC] aharvey@php.net 
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=303712
Log: Fix doc bug #52909 by documenting the extra parameters available in
PharData::__construct().
 [2010-09-23 06:52 UTC] aharvey@php.net
-Status: Assigned +Status: Closed
 [2010-09-23 06:52 UTC] aharvey@php.net 
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.
 [2010-09-23 17:37 UTC] aharvey@php.net
-Status: Closed +Status: Assigned -Type: Documentation Problem +Type: Bug
 [2010-09-23 17:37 UTC] aharvey@php.net 
Reopening per IRC discussion.
 [2012-09-11 16:50 UTC] reeze@php.net 
Hi aharvey
   reopen and what to do next :)
 [2015-03-29 07:12 UTC] mike@php.net 
See also bug #69196
 [2015-03-29 07:13 UTC] mike@php.net 
Related To: Bug #69196
 [2015-03-30 02:23 UTC] reeze@php.net 
Hi Mike,

The bug #69196 could be fixed by specify different arg info IMO.

class Phar and PharData shared the most of the implementation, we could either fix doc or fix implementation, but as the documentation exist so long, I do prefer fix the implementation.
 [2017-10-24 07:18 UTC] kalle@php.net
-Status: Assigned +Status: Open -Assigned To: aharvey +Assigned To:
 [2018-08-05 01:49 UTC] carusogabriel@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: carusogabriel
 [2018-08-05 01:49 UTC] carusogabriel@php.net 
Closing as the number of arguments for Phar::__construct() was solved: https://3v4l.org/Tc7eL.

We should now focus on Bug #69196.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 19:01:29 2024 UTC