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

go to bug id or search bugs for

Bug #58529 PHP doc not properly handled for extending classes
Submitted: 2009-01-29 17:54 UTC Modified: 2009-05-05 14:50 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: jason at pirkplace dot com Assigned:
Status: No Feedback Package: APC (PECL)
PHP Version: 5.1.6 OS: CentOS 5.2, Apache 2.2.X
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: jason at pirkplace dot com
New email:
PHP Version: OS:

 

 [2009-01-29 17:54 UTC] jason at pirkplace dot com 
Description:
------------
I am pretty sure it has to do with the caching of classes that are in files.

So my setup is I have classes that I extend off of each other separate files.

First load of the class (after it is saved to the filesystem) produces the correct results.  The each subsequent run of the script produces the incorrect php doc for the specified property.  It only happens when the classes are stored in separate files -- can not reproduce with all the code in one script.

If Class C extends Class B extends Class A, and there is a property defined in Class A and redefined in Class B with different PHP doc, the original php doc in Class A is used on a subsequent Reflect getDocComments call on Class C instead of the overridden PHP doc in Class B.  The code example at the URL listed probably explains this better.



If I move the property to the 



Reproduce code:
---------------
http://www.pirkplace.com/BugReports/PECL-APC/phpdoc.html

Expected result:
----------------
The proper php doc of the property.

/**
 * Primary identifier of the customer
 * 
 * @bindname customer_id
 * @var int
 */




Actual result:
--------------
First load is correct:

/**
 * Primary identifier of the customer
 * 
 * @bindname customer_id
 * @var int
 */


Additional loads:

/**
 * Unique Identifier for the object
 * 
 * @bindname ID
 * @var int
 */

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-01-29 22:26 UTC] jason at pirkplace dot com 
The Description got cut off.  The last sentence states: "If I move the property and phpdoc to Class C it works fine."
 [2009-02-03 23:51 UTC] gopalv82 at yahoo dot com 
Looking at it, this looks like an interesting side-effect of 
ignoring reflection (because it sucks for performance).

Anyway, taking a closer look at the op_array->doc_comment stuff.

Thanks
 [2009-02-04 03:31 UTC] gopalv82 at yahoo dot com 
I just ran a test with 5.3.x and it seems to work fine.

Which is really weird in some sense. All loads work just 
fine, which suggests the fix would've been elsewhere.
 [2009-02-04 11:46 UTC] jason at pirkplace dot com 
"All loads" == 5.3, 5.2 and 5.1.6?

I have not tried it on our 5.2.8 version running (that I hand compile).  I will try tonight or tomorrow.

I am using the yum package for Centos 5.
[root@webdev-01 ~]# yum list installed | grep php
php.x86_64                               5.1.6-20.el5_2.1       installed       
php-bcmath.x86_64                        5.1.6-20.el5_2.1       installed       
php-cli.x86_64                           5.1.6-20.el5_2.1       installed       
php-common.x86_64                        5.1.6-20.el5_2.1       installed       
php-devel.x86_64                         5.1.6-20.el5_2.1       installed       
php-gd.x86_64                            5.1.6-20.el5_2.1       installed       
php-mbstring.x86_64                      5.1.6-20.el5_2.1       installed       
php-mssql.x86_64                         5.1.6-15.el5.centos.1  installed       
php-pear.noarch                          1:1.4.9-4.el5.1        installed       
php-pecl-memcache.x86_64                 2.2.3-1.el5_2          installed       
php-snmp.x86_64                          5.1.6-20.el5_2.1       installed       
php-xml.x86_64                           5.1.6-20.el5_2.1       installed   


[root@webdev-01 ~]# uname -a
Linux webdev-01 2.6.18-92.1.13.el5 #1 SMP Wed Sep 24 19:32:05 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux


APC module output from phpinfo():


APC Support 	enabled
Version 	3.0.19
MMAP Support 	Enabled
MMAP File Mask 	no value
Locking type 	pthread mutex Locks
Revision 	$Revision: 3.154.2.5 $
Build Date 	Aug 25 2008 18:27:19

Directive			Value
apc.cache_by_default		On
apc.coredump_unmap		Off
apc.enable_cli			Off
apc.enabled			On
apc.file_update_protection	2
apc.filters			no value
apc.gc_ttl			3600
apc.include_once_override	Off
apc.max_file_size		1M
apc.mmap_file_mask		no value
apc.num_files_hint		1000
apc.report_autofilter		Off
apc.shm_segments		1
apc.shm_size			30
apc.slam_defense		no value
apc.stat			On
apc.stat_ctime			Off
apc.ttl				0
apc.user_entries_hint		4096
apc.user_ttl			0
apc.write_lock			On

Let me know if there is anything else I can do to help you.
 [2009-02-05 08:20 UTC] gopalv82 at yahoo dot com 
No, I mean with 5.3 build that I'm working on now - it works out of the box.

Could you please test 3.1.2 and confirm if it still exists?
 [2009-02-06 13:45 UTC] jason at pirkplace dot com 
Been really busy at work last couple days, I will try to get to this on Monday (2009-02-09)

Sorry for the delay
 [2009-03-18 14:30 UTC] shire@php.net 
Just want to check and see if you've had chance to verify this.  Thanks!
 [2009-05-05 14:50 UTC] shire@php.net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Apr 20 16:01:29 2024 UTC