Bug #41145 [Com]: Interface, Abstract Class & Methods
Edit report at https://bugs.php.net/bug.php?id=41145&edit=1
ID: 41145
Comment by: lsm...@php.net
Reported by:gerald at copix dot org
Summary:Interface, Abstract Class & Methods
Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Linux
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
see #43200
Previous Comments:
[2007-04-21 20:56:07] he...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This kind of inhereitance trickery is only useful and working in languages that
support MI and there you need to have the leave class reimplement the method or
explicitly use one of the base class\' implementation regardless of whether you
provide new code or not. This is the case because both the abstract class and
the interface are two independant origins of the method. Thus they are
considered different. What you can do instead is having a basic interface that
only contains the shared method. Doing so is absolutely correct because as you
say they are the same protocol entity. And if you were not able to ürovide a
shared base for them, than indeed the methods are different.
[2007-04-20 08:00:05] gerald at copix dot org
Description:
When we want to implement an interface in a child class that extends an
abstract class that contains an abstract method that is in the interface, we
get an error.
This kind of bug has already been submited in #35057 and was marked as bogus
because AClasse::show obviously is not the same as IClasse::show.
But in the code we only say that IClasse::show is the same as
AClasseConcrete::show.
To me, the IClasse should not care how AClasseConcrete manage to implements the
interface. The important thing is that AClasseConcrete::show IS the same as
IClasse::show.
I've checked the documentation and was not able to find this exact case and
I've try this concept in other langages (like Java) with success.
I think at least it should be discussed.
If it has been discussed already, I'm really sorry for the time I made you
spent on this.
Greatings
Reproduce code:
---
interface IClasse {
public function show ();
}
abstract class AClasse {
abstract public function show ();
}
class AClasseConcrete extends AClasse implements IClasse {
public function show (){
echo "Everything is ok";
}
}
$classe = new AClasseConcrete ();
$classe->show ();
Expected result:
"Everything is ok"
Actual result:
--
Fatal error: Can't inherit abstract function IClasse::show() (previously
declared abstract in AClasse) in
/home/geraldc/workspace/Copix_3/www/syntax_playground.php
--
Edit this bug report at https://bugs.php.net/bug.php?id=41145&edit=1
Bug #35057 [Com]: abstract method inheritance and interface implementation problem
Edit report at https://bugs.php.net/bug.php?id=35057&edit=1 ID: 35057 Comment by: lsm...@php.net Reported by:antonsub at pochtamt dot ru Summary:abstract method inheritance and interface implementation problem Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.1.0RC4 Block user comment: N Private report: N New Comment: see #43200 Previous Comments: [2005-11-01 21:53:46] he...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php B::foo is not A::foo, so when C inherits B it gets B::foo and when it implements A it gets A:foo, obviously A::foo and B::foo are different. That\'s what the error tells you. [2005-11-01 21:12:39] antonsub at pochtamt dot ru Description: Code given produces fatal error: Can't inherit abstract function A::foo() (previously declared abstract in B) in foo.php on line 20 Reproduce code: --- Expected result: But is expected to run cleanly. -- Edit this bug report at https://bugs.php.net/bug.php?id=35057&edit=1
[PHP-BUG] Req #61739 [NEW]: make it possible to read path from JPEG image
From: lsmith Operating system: irrelevant PHP version: Irrelevant Package: *Graphics related Bug Type: Feature/Change Request Bug description:make it possible to read path from JPEG image Description: it seems like Photoshop has extended JPEG to be able to embed path information. it would be useful to extract this information see the following link for details http://forums.adobe.com/thread/618583 http://stackoverflow.com/questions/3030577/is-it-possible-to-read-path-in-jpeg- image-with-python -- Edit bug report at https://bugs.php.net/bug.php?id=61739&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61739&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61739&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61739&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61739&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61739&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61739&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61739&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61739&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61739&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61739&r=support Expected behavior: https://bugs.php.net/fix.php?id=61739&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61739&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61739&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61739&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61739&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61739&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61739&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61739&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61739&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61739&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61739&r=mysqlcfg
[PHP-BUG] Bug #62956 [NEW]: "incompatible" signatures for private methods should not cause E_STRICT
From: lsmith Operating system: PHP version: 5.4.6 Package: Unknown/Other Function Bug Type: Bug Bug description:"incompatible" signatures for private methods should not cause E_STRICT Description: Defining a private method in an extending class that matches the name of a private method in a parent class with a different signature currently triggers an E_STRICT. As the extending class shouldn't see the parent private methods, there is no reason to trigger an E_STRICT in this case. Test script: --- https://bugs.php.net/bug.php?id=62956&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62956&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62956&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62956&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62956&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62956&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62956&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62956&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62956&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62956&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62956&r=support Expected behavior: https://bugs.php.net/fix.php?id=62956&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62956&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62956&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62956&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62956&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62956&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62956&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62956&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62956&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62956&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62956&r=mysqlcfg
Bug #62956 [Com]: "incompatible" signatures for private methods should not cause E_STRICT
Edit report at https://bugs.php.net/bug.php?id=62956&edit=1 ID: 62956 Comment by: lsm...@php.net Reported by: lsm...@php.net Summary:"incompatible" signatures for private methods should not cause E_STRICT Status: Open Type: Bug Package:Unknown/Other Function PHP Version:5.4.6 Block user comment: N Private report: N New Comment: BTW: A temporary fix is to simply rename the method in the extending class. Previous Comments: [2012-08-28 10:58:59] lsm...@php.net Description: Defining a private method in an extending class that matches the name of a private method in a parent class with a different signature currently triggers an E_STRICT. As the extending class shouldn't see the parent private methods, there is no reason to trigger an E_STRICT in this case. Test script: --- https://bugs.php.net/bug.php?id=62956&edit=1
Bug #51091 [Com]: Persistent PDO Connections Crash
Edit report at http://bugs.php.net/bug.php?id=51091&edit=1 ID: 51091 Comment by: lsm...@php.net Reported by:achristianson at yakabod dot com Summary:Persistent PDO Connections Crash Status: Closed Type: Bug Package:Reproducible crash Operating System: CentOS 5.4 PHP Version:5.3.1 Assigned To:dmitry Block user comment: N Private report: N New Comment: I am also seeing segfaults/bus errors, which go away after disabling GC on PHP 5.3.4 using PostgreSQL via Doctrine 2.0. Though the issues only appeared when I added ext intl. I am seeing these issues on OSX and Debian. Previous Comments: [2010-10-12 00:50:57] fel...@php.net I can't reproduce this as well. (probably already fixed...) [2010-09-10 00:01:21] matth+php at mlalonde dot net For the record, we are using Doctrine 2.0 (which uses the PDO) and PostgreSQL. [2010-09-09 23:54:58] matth+php at mlalonde dot net I can replicate under Ubuntu Server LTS 10.04 running nginx and php-fcgi (using spawn fcgi). Reading symbols from /usr/lib/gconv/ISO8859-1.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so Core was generated by `/usr/bin/php5-cgi'. Program terminated with signal 11, Segmentation fault. #0 0x006b2ea9 in gc_zval_possible_root (zv=0x4c7d018) at /build/buildd/php5-5.3.2/Zend/zend_gc.c:143 143 /build/buildd/php5-5.3.2/Zend/zend_gc.c: No such file or directory. in /build/buildd/php5-5.3.2/Zend/zend_gc.c (gdb) bt #0 0x006b2ea9 in gc_zval_possible_root (zv=0x4c7d018) at /build/buildd/php5-5.3.2/Zend/zend_gc.c:143 #1 0x006a1698 in zend_hash_destroy (ht=0x4c7ce20) at /build/buildd/php5-5.3.2/Zend/zend_hash.c:726 #2 0x0054e1ed in sxe_object_free_storage (object=0x4c7bcc0) at /build/buildd/php5-5.3.2/ext/simplexml/simplexml.c:2016 #3 0x006b9aec in zend_objects_store_free_object_storage (objects=0xd8fd18) at /build/buildd/php5-5.3.2/Zend/zend_objects_API.c:92 #4 0x00688ac5 in shutdown_executor () at /build/buildd/php5-5.3.2/Zend/zend_execute_API.c:302 #5 0x006953e2 in zend_deactivate () at /build/buildd/php5-5.3.2/Zend/zend.c:962 #6 0x00641095 in php_request_shutdown (dummy=0x4c7d018) at /build/buildd/php5-5.3.2/main/main.c:1649 #7 0x00722550 in main (argc=32767, argv=0x0) at /build/buildd/php5-5.3.2/sapi/cgi/cgi_main.c:2160 [2010-06-28 05:15:54] dxm007 at gmail dot com Hi, I've been trying to setup Menalto Gallery and after I got through entire setup of a fresh installation (to verify php, MSSQL, IIS were working fine), I pointed the gallery to my existing database and flat files. Because my data came from an older version of the Gallery, it invokes upgrade wizard which dies every single time on step 2. I've created a crash dump with adplus and it appears to be exactly the same bug as what's reported here. This is 100% repeatable on my machine. I'm using PHP 5.3.2 with Windows 2008 Server R2, IIS7 and MSSQL 2008 R2. I've also been able to get past the crash by adding "zend.enable_gc = Off" to php.ini [2010-04-20 18:11:48] dmi...@php.net I'm not able to reproduce it. May be it's already fixed. Could you verify? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51091 -- Edit this bug report at http://bugs.php.net/bug.php?id=51091&edit=1
Bug #51091 [Com]: Persistent PDO Connections Crash
Edit report at http://bugs.php.net/bug.php?id=51091&edit=1 ID: 51091 Comment by: lsm...@php.net Reported by:achristianson at yakabod dot com Summary:Persistent PDO Connections Crash Status: Closed Type: Bug Package:Reproducible crash Operating System: CentOS 5.4 PHP Version:5.3.1 Assigned To:dmitry Block user comment: N Private report: N New Comment: I should add that I have only seen this issue when running my entire test suite on the CLI. Running the crashing unit tests individually makes the issue go away. Previous Comments: [2010-12-27 23:03:57] lsm...@php.net I am also seeing segfaults/bus errors, which go away after disabling GC on PHP 5.3.4 using PostgreSQL via Doctrine 2.0. Though the issues only appeared when I added ext intl. I am seeing these issues on OSX and Debian. [2010-10-12 00:50:57] fel...@php.net I can't reproduce this as well. (probably already fixed...) [2010-09-10 00:01:21] matth+php at mlalonde dot net For the record, we are using Doctrine 2.0 (which uses the PDO) and PostgreSQL. [2010-09-09 23:54:58] matth+php at mlalonde dot net I can replicate under Ubuntu Server LTS 10.04 running nginx and php-fcgi (using spawn fcgi). Reading symbols from /usr/lib/gconv/ISO8859-1.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so Core was generated by `/usr/bin/php5-cgi'. Program terminated with signal 11, Segmentation fault. #0 0x006b2ea9 in gc_zval_possible_root (zv=0x4c7d018) at /build/buildd/php5-5.3.2/Zend/zend_gc.c:143 143 /build/buildd/php5-5.3.2/Zend/zend_gc.c: No such file or directory. in /build/buildd/php5-5.3.2/Zend/zend_gc.c (gdb) bt #0 0x006b2ea9 in gc_zval_possible_root (zv=0x4c7d018) at /build/buildd/php5-5.3.2/Zend/zend_gc.c:143 #1 0x006a1698 in zend_hash_destroy (ht=0x4c7ce20) at /build/buildd/php5-5.3.2/Zend/zend_hash.c:726 #2 0x0054e1ed in sxe_object_free_storage (object=0x4c7bcc0) at /build/buildd/php5-5.3.2/ext/simplexml/simplexml.c:2016 #3 0x006b9aec in zend_objects_store_free_object_storage (objects=0xd8fd18) at /build/buildd/php5-5.3.2/Zend/zend_objects_API.c:92 #4 0x00688ac5 in shutdown_executor () at /build/buildd/php5-5.3.2/Zend/zend_execute_API.c:302 #5 0x006953e2 in zend_deactivate () at /build/buildd/php5-5.3.2/Zend/zend.c:962 #6 0x00641095 in php_request_shutdown (dummy=0x4c7d018) at /build/buildd/php5-5.3.2/main/main.c:1649 #7 0x00722550 in main (argc=32767, argv=0x0) at /build/buildd/php5-5.3.2/sapi/cgi/cgi_main.c:2160 [2010-06-28 05:15:54] dxm007 at gmail dot com Hi, I've been trying to setup Menalto Gallery and after I got through entire setup of a fresh installation (to verify php, MSSQL, IIS were working fine), I pointed the gallery to my existing database and flat files. Because my data came from an older version of the Gallery, it invokes upgrade wizard which dies every single time on step 2. I've created a crash dump with adplus and it appears to be exactly the same bug as what's reported here. This is 100% repeatable on my machine. I'm using PHP 5.3.2 with Windows 2008 Server R2, IIS7 and MSSQL 2008 R2. I've also been able to get past the crash by adding "zend.enable_gc = Off" to php.ini The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51091 -- Edit this bug report at http://bugs.php.net/bug.php?id=51091&edit=1
