#34243 [NEW]: ReflectionClass::getDocComment() returns no result
From: colin at encode dot net dot au
Operating system: Win XP SP2
PHP version: 5.1.0RC1
PHP Bug Type: Scripting Engine problem
Bug description: ReflectionClass::getDocComment() returns no result
Description:
The getDocComment() method from the Reflection API (in this case, the
ReflectionClass class) returns no result where an if block exists before
the documentation comment.
Reproduce code:
---
if (!class_exists('AnotherObject'))
{
require(anotherobject.php);
}
/**
* Comment to test getDocComment()
*/
class TestObject
{
}
$rclass = new ReflectionClass('TestObject');
echo Comment: '.$rclass-getDocComment().';
Expected result:
Comment: '/** * Comment to test getDocComment() */'
Actual result:
--
Comment: ''
--
Edit bug report at http://bugs.php.net/?id=34243edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34243r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34243r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34243r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34243r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34243r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34243r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34243r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34243r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34243r=support
Expected behavior: http://bugs.php.net/fix.php?id=34243r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34243r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34243r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34243r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34243r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34243r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34243r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34243r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34243r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34243r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34243r=mysqlcfg
#33571 [Bgs-Opn]: PHPIniDir directive appears to be ignored
ID: 33571 User updated by: colin at encode dot net dot au Reported By: colin at encode dot net dot au -Status: Bogus +Status: Open Bug Type: Apache2 related Operating System: Windows XP Professional SP2 PHP Version: 5.1.0b2 New Comment: Hello Derick, Since I just followed the same installation process with PHP 5.0.4, and it *worked* as expected, I would say that this does imply a bug in PHP 5.1.0b2, wouldn't you agree? Regards, Colin. Previous Comments: [2005-07-05 09:14:57] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. . [2005-07-05 03:09:21] colin at encode dot net dot au Description: Hello, I understand this is a beta version of PHP but felt I should report that it appears the PHPIniDir Apache configuration directive is ignored by this release of PHP. I installed PHP according to the install.txt instructions and configured the httpd.conf of Apache 2.0.54 using the directives below: # # Load PHP5 module: # LoadModule php5_module C:/PHP/php5apache2.dll # # To use PHP scripts: # AddType application/x-httpd-php .php # # Define php.ini path: # PHPIniDir C:/PHP To begin with I renamed the php.ini-recommended file to php.ini within the C:/PHP folder. PHP would not load correctly however, and upon accessing a phpinfo test page within the browser I would receive the PHP code itself within the browser window, i.e: ?php phpinfo(); ? ...would appear in the page source. I also tried adding the PHP path to the path and PHPRC environment variables with no success. Upon removing the php.ini from C:/PHP, PHP appeared to load but would report C:\WINDOWS in the Configuration File (php.ini) Path field of the phpinfo() output. Note, there is no php.ini file in C:\WINDOWS. -- Edit this bug report at http://bugs.php.net/?id=33571edit=1
#33571 [NEW]: PHPIniDir directive appears to be ignored
From: colin at encode dot net dot au Operating system: Windows XP Professional SP2 PHP version: 5.1.0b2 PHP Bug Type: Apache2 related Bug description: PHPIniDir directive appears to be ignored Description: Hello, I understand this is a beta version of PHP but felt I should report that it appears the PHPIniDir Apache configuration directive is ignored by this release of PHP. I installed PHP according to the install.txt instructions and configured the httpd.conf of Apache 2.0.54 using the directives below: # # Load PHP5 module: # LoadModule php5_module C:/PHP/php5apache2.dll # # To use PHP scripts: # AddType application/x-httpd-php .php # # Define php.ini path: # PHPIniDir C:/PHP To begin with I renamed the php.ini-recommended file to php.ini within the C:/PHP folder. PHP would not load correctly however, and upon accessing a phpinfo test page within the browser I would receive the PHP code itself within the browser window, i.e: ?php phpinfo(); ? ...would appear in the page source. I also tried adding the PHP path to the path and PHPRC environment variables with no success. Upon removing the php.ini from C:/PHP, PHP appeared to load but would report C:\WINDOWS in the Configuration File (php.ini) Path field of the phpinfo() output. Note, there is no php.ini file in C:\WINDOWS. -- Edit bug report at http://bugs.php.net/?id=33571edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33571r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33571r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33571r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33571r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33571r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33571r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33571r=needscript Try newer version: http://bugs.php.net/fix.php?id=33571r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33571r=support Expected behavior: http://bugs.php.net/fix.php?id=33571r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33571r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33571r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33571r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33571r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33571r=dst IIS Stability: http://bugs.php.net/fix.php?id=33571r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33571r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33571r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33571r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33571r=mysqlcfg
#30350 [NEW]: Returning reference to array element produces strange result
From: colin at encode dot net dot au
Operating system: Windows XP Pro SP2
PHP version: 5.0.2
PHP Bug Type: Arrays related
Bug description: Returning reference to array element produces strange result
Description:
I'm not entirely sure if this is a bug or not, but it seems very odd
nonetheless. I have an array of attributes as a protected class property,
and some simple functions to manipulate this array:
?php
class Test
{
protected $attributes;
public function __construct()
{
$this-attributes = array();
}
public function setAttribute($name=null,$value=null)
{
$this-attributes[$name] = $value;
}
public function getAttribute($name=null)
{
return $this-attributes[$name];
}
}
$test = new Test();
$test-setAttribute('foo','bar');
$test-setAttribute('omg','bbq');
echo $test-getAttribute('foo');
echo $test-getAttribute('eep');
print_r($test);
?
Upon executing this code we should define two elements in the attributes
array, show the output of one, then generate a notice error because the
index 'eep' does not exist, and then receive a dump of the $test object,
which should look like this:
Test Object
(
[attributes:protected] = Array
(
[foo] = bar
[omg] = bbq
)
)
This is all fine and to be expected. Now typically with code like this in
PHP4, I would have used an ampersand in front of the getAttribute function
definition to allow a reference to an attribute array element to be
returned. To my understanding only objects are *always* passed around by
reference in PHP5, everything else is still copied (though I may be
wrong), so that would seem to imply to me that we still need the ampersand
to allow a reference to be returned. So let's see what happens when we put
an ampersand in front of the getAttribute function definition above, like
so:
public function getAttribute($name=null)
{
return $this-attributes[$name];
}
Ok, upon execution now, I receive *no* notice error that the index 'eep'
does not exist - instead, a new null element is added to the array mapped
to the key 'eep'. The print_r($test) now shows:
Test Object
(
[attributes:protected] = Array
(
[foo] = bar
[omg] = bbq
[eep] =
)
)
What gives? Am I doing something really stupid? I don't understand this.
--
Edit bug report at http://bugs.php.net/?id=30350edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30350r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30350r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30350r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30350r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30350r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30350r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30350r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30350r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30350r=support
Expected behavior: http://bugs.php.net/fix.php?id=30350r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30350r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30350r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30350r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30350r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30350r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30350r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30350r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30350r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30350r=mysqlcfg
#30350 [Opn-Bgs]: Returning reference to array element produces strange result
ID: 30350
User updated by: colin at encode dot net dot au
Reported By: colin at encode dot net dot au
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Windows XP Pro SP2
PHP Version: 5.0.2
New Comment:
Ok, it appears that the element is created because we are attempting to
return a reference to something that does not exist. Updating status.
:)
Previous Comments:
[2004-10-07 05:26:07] colin at encode dot net dot au
Description:
I'm not entirely sure if this is a bug or not, but it seems very odd
nonetheless. I have an array of attributes as a protected class
property, and some simple functions to manipulate this array:
?php
class Test
{
protected $attributes;
public function __construct()
{
$this-attributes = array();
}
public function setAttribute($name=null,$value=null)
{
$this-attributes[$name] = $value;
}
public function getAttribute($name=null)
{
return $this-attributes[$name];
}
}
$test = new Test();
$test-setAttribute('foo','bar');
$test-setAttribute('omg','bbq');
echo $test-getAttribute('foo');
echo $test-getAttribute('eep');
print_r($test);
?
Upon executing this code we should define two elements in the
attributes array, show the output of one, then generate a notice error
because the index 'eep' does not exist, and then receive a dump of the
$test object, which should look like this:
Test Object
(
[attributes:protected] = Array
(
[foo] = bar
[omg] = bbq
)
)
This is all fine and to be expected. Now typically with code like this
in PHP4, I would have used an ampersand in front of the getAttribute
function definition to allow a reference to an attribute array element
to be returned. To my understanding only objects are *always* passed
around by reference in PHP5, everything else is still copied (though I
may be wrong), so that would seem to imply to me that we still need the
ampersand to allow a reference to be returned. So let's see what
happens when we put an ampersand in front of the getAttribute function
definition above, like so:
public function getAttribute($name=null)
{
return $this-attributes[$name];
}
Ok, upon execution now, I receive *no* notice error that the index
'eep' does not exist - instead, a new null element is added to the
array mapped to the key 'eep'. The print_r($test) now shows:
Test Object
(
[attributes:protected] = Array
(
[foo] = bar
[omg] = bbq
[eep] =
)
)
What gives? Am I doing something really stupid? I don't understand
this.
--
Edit this bug report at http://bugs.php.net/?id=30350edit=1
