Bug #52330 [Wfx]: __construct() method should always return a new instance
Edit report at http://bugs.php.net/bug.php?id=52330&edit=1 ID: 52330 User updated by: whistl0r+phpbug at googlemail dot com Reported by: whistl0r+phpbug at googlemail dot com Summary: __construct() method should always return a new instance Status: Wont fix Type:Bug Package: Class/Object related PHP Version: Irrelevant New Comment: > Basically, if you don't want __construct() to act like a method call, > don't call it like a method call. Well, why does PHP supports different visibilities like "public", "protected" or "private"? You can tell the programmer, "don't read the variable, it's private!" like you say "don't call it like a method". ;) You support it, because it is part of the OOP concept (encapsulation). Other languages like Java or C# doesn't allow you to call the constructor like a method. The constructor is only callable with "new" (because it's not a normal method). Currently, to be safe from OOP view, it seems to me like you must add something like protected $_initiated = false to your class. If this is "true", your constructor method will end. This would make sure, that the constructor will only run once and you object cannot enter an unexpected state, because someone calls the constructor again... Previous Comments: [2010-07-13 18:34:08] ahar...@php.net That might seem odd, but it seems consistent enough to me. It breaks down one of two ways: 1. You call the constructor by instantiating an object with new. It behaves like a constructor -- return values are ignored and a new object instance is created. 2. You call the constructor by calling $object->__construct(). It behaves like a method call, including return values being returned. Basically, if you don't want __construct() to act like a method call, don't call it like a method call. ---- [2010-07-13 16:35:38] whistl0r+phpbug at googlemail dot com Description: Please see the test script. This should be normal PHP 5.3 class with a good OOP design. In PHP it is possible, that I can call the constructor multiple times, for example: $person = new \My\Person('Jens', 'Mander'); echo sprintf('Name: %s %s', $person->getName(), $person->getSurname()); // Will output "Name: Jens Mander" $person->__construct('John', 'Doe'); echo sprintf('Name: %s %s', $person->getName(), $person->getSurname()); // Will output "Name: John Doe" In my understanding, it is unexpected, that 1) you can access the constructor method in an instantiated object. The constructor should only instantiate the object - when you have the object, there is no need to call it again. If you need something to "reset" your object state, you should implement such a method. 2) If you can call the constructor again, that it will change the object and *not* return a new instance. For example: If you add a "return new \stdClass();" line to your constructor, it will still change the instance you called it from, but now it will also return a "stdClass" - that's inconsistent, isn't it? Test script: --- setName($name); } if ($surname !== null) { $this->setSurname($surname); } } /** * Returns the name. * * @return null|string Null, when no name was set */ public function getName() { return $this->_name; } /** * Returns the surname. * * @return null|string Null, when no name was set */ public function getSurname() { return $this->_surname; } /** * Set the name. * * @param string $name * @return \My\Person Provides fluent interface * @throws \Exception */ public function setName($name) { if (!is_string($name) || empty($name)) { throw new \Exception('Name cannot be empty and must be a string!'); } $this->_name = $name; return $this; } /** * Set the surname. * * @param string $name * @return \My\Person Provides fluent interface * @throws \Exception When $name isn't a string or empty */ public function setSurname($name) { if (!is_string($name) || empty($name)) { throw new \Exception('Name cannot be empty and must be a string!'); } $this->_surname = $name; return $this; } } Expected result: - FATAL error e.g. "Object already constructed!" - The __construct() call should return a *new* object. Actual result: -- The __construct() method will work on the object, from where you called it. -- Edit this bug report at http://bugs.php.net/bug.php?id=52330&edit=1
[PHP-BUG] Bug #52330 [NEW]: __construct() method should always return a new instance
From: Operating system: PHP version: Irrelevant Package: Class/Object related Bug Type: Bug Bug description:__construct() method should always return a new instance Description: Please see the test script. This should be normal PHP 5.3 class with a good OOP design. In PHP it is possible, that I can call the constructor multiple times, for example: $person = new \My\Person('Jens', 'Mander'); echo sprintf('Name: %s %s', $person->getName(), $person->getSurname()); // Will output "Name: Jens Mander" $person->__construct('John', 'Doe'); echo sprintf('Name: %s %s', $person->getName(), $person->getSurname()); // Will output "Name: John Doe" In my understanding, it is unexpected, that 1) you can access the constructor method in an instantiated object. The constructor should only instantiate the object - when you have the object, there is no need to call it again. If you need something to "reset" your object state, you should implement such a method. 2) If you can call the constructor again, that it will change the object and *not* return a new instance. For example: If you add a "return new \stdClass();" line to your constructor, it will still change the instance you called it from, but now it will also return a "stdClass" - that's inconsistent, isn't it? Test script: --- setName($name); } if ($surname !== null) { $this->setSurname($surname); } } /** * Returns the name. * * @return null|string Null, when no name was set */ public function getName() { return $this->_name; } /** * Returns the surname. * * @return null|string Null, when no name was set */ public function getSurname() { return $this->_surname; } /** * Set the name. * * @param string $name * @return \My\Person Provides fluent interface * @throws \Exception */ public function setName($name) { if (!is_string($name) || empty($name)) { throw new \Exception('Name cannot be empty and must be a string!'); } $this->_name = $name; return $this; } /** * Set the surname. * * @param string $name * @return \My\Person Provides fluent interface * @throws \Exception When $name isn't a string or empty */ public function setSurname($name) { if (!is_string($name) || empty($name)) { throw new \Exception('Name cannot be empty and must be a string!'); } $this->_surname = $name; return $this; } } Expected result: - FATAL error e.g. "Object already constructed!" - The __construct() call should return a *new* object. Actual result: -- The __construct() method will work on the object, from where you called it. -- Edit bug report at http://bugs.php.net/bug.php?id=52330&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52330&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52330&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52330&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52330&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52330&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52330&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52330&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52330&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52330&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52330&r=support Expected behavior: http://bugs.php.net/fix.php?id=52330&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52330&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52330&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52330&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52330&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52330&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52330&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52330&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52330&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52330&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52330&r=mysqlcfg
Req #45586 [Com]: php_mbstring must be loaded before php_exif extension in php.ini
Edit report at http://bugs.php.net/bug.php?id=45586&edit=1 ID: 45586 Comment by: whistl0r+phpbug at googlemail dot com Reported by: bouke at haarsma dot eu Summary: php_mbstring must be loaded before php_exif extension in php.ini Status: Open Type: Feature/Change Request Package: Feature/Change Request Operating System: Windows XP PHP Version: 5.2.6 New Comment: This problem also affects PHP 5.3 (tested against the latest 5.3.2 release for Windows). If you cannot change the order (I agree missingno's argumentation), this should be documented! Google for the term "php_exif not found", you will find many reports like http://eligeske.com/wordpress/php_exif-dll-the-specified-module-could-not-be- found/ Previous Comments: [2008-07-23 09:54:31] missingno at ifrance dot com I guess the problem comes from the fact that the extension entries are sorted by alphabetical order in the php.ini file. Correcting the order of extensions would solve the problem but would require a lot of testing because I think this problem also occurs with other extensions as well... I don't think it is such a good idea because the way the list is currently written makes it easy to find the extensions you want to activate. Also, each extension's page in the manual clearly has some sort of a FAQ regarding installation/configuration. The only problem I seen then is users that do not read the manual, but I digress... Anyway, I think this is a WONTFIX for now. One possible solution would be for extensions to manage dependancies at runtime and let the user know the steps to follow in order for the extension to work. But this would probably put to much of a burden on the developpers compared to the actual gain. [2008-07-21 17:30:45] j...@php.net Better summary. There's no crash here. [2008-07-21 17:17:19] bouke at haarsma dot eu Description: Please see: http://bugs.php.net/bug.php?id=27248 Also see: http://bugs.php.net/bug.php?id=32552 Using the latest php.ini files, the problem still exists. The default order for loading the extensions is wrong and error-prone. The 'solution' as stated in the comments should also be reflected in the php.ini-file. Please note that this has been "solved" in 2005, but the bug is introduced again. Reproduce code: --- Enter this into php.ini: extension=php_exif.dll extension=php_mbstring.dll Solution: extension=php_mbstring.dll extension=php_exif.dll (Swaped order) Expected result: -no error message- Actual result: -- -error message: "php_mbstring.dll" not found -- Edit this bug report at http://bugs.php.net/bug.php?id=45586&edit=1
[PHP-BUG] Bug #51953 [NEW]: realpath isn't resolving symlinks/junctions
From: Operating system: Windows Vista/7 PHP version: 5.2.13 Package: Directory function related Bug Type: Bug Bug description:realpath isn't resolving symlinks/junctions Description: This bug is maybe related to http://bugs.php.net/bug.php?id=51952 Your in your httpd.conf configured DOCUMENT_ROOT is "C:\Sites\example.org\htdocs". But this isn't a folder, it's a symlink/junction to the following folder: "C:\Foo". Now you call "C:\Sites\example.org\htdocs\test.php" Test script: --- http://bugs.php.net/bug.php?id=51953&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51953&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51953&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=51953&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=51953&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51953&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51953&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51953&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51953&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51953&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51953&r=support Expected behavior: http://bugs.php.net/fix.php?id=51953&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51953&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51953&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51953&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51953&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51953&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51953&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51953&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51953&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51953&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51953&r=mysqlcfg
Bug #51952 [Com]: __FILE__ and dirname() are returning wrong pathes when working with junctions
Edit report at http://bugs.php.net/bug.php?id=51952&edit=1 ID: 51952 Comment by: whistl0r+phpbug at googlemail dot com Reported by: whistl0r+phpbug at googlemail dot com Summary: __FILE__ and dirname() are returning wrong pathes when working with junctions Status: Open Type: Bug Package: Directory function related Operating System: Windows Vista/7 PHP Version: 5.2.13 New Comment: I found this inconsistent behavior, after upgrading to PHP 5.3, because a required once call (required_once realpath(dirname(__FILE__) . '/../configs/main.php');) failed. It failed because PHP 5.3 resolves the symlinks. I checked the documentation and it says that this is the wanted behavior. So it seems like, because it nothing new in PHP 5.3, that it must be a bug in PHP 5.2. Previous Comments: [2010-05-31 01:39:52] whistl0r+phpbug at googlemail dot com Description: Consister the following setup: You keep your source code in "C:\Repositories\example.org\trunk". You just point your DOCUMENT_ROOT to that folder via symlink/junction: httpd.conf: [...] DOCUMENT_ROOT "C:\Sites\example.org\htdocs" [...] C:\Sites\example.org>dir Volume in drive D is System Volume Serial Number is E49D-A2E7 Directory of C:\Sites\example.org 2010-05-31 01:08 . 2010-05-31 01:08 .. 2010-05-31 01:08 htdocs [C:\Repositories\example.org\trunk] You now run the script "C:\Sites\example.org\htdocs\test.php". Test script: --- http://bugs.php.net/bug.php?id=51952&edit=1
[PHP-BUG] Bug #51952 [NEW]: __FILE__ and dirname() are returning wrong pathes when working with junctions
From: Operating system: Windows Vista/7 PHP version: 5.2.13 Package: Directory function related Bug Type: Bug Bug description:__FILE__ and dirname() are returning wrong pathes when working with junctions Description: Consister the following setup: You keep your source code in "C:\Repositories\example.org\trunk". You just point your DOCUMENT_ROOT to that folder via symlink/junction: httpd.conf: [...] DOCUMENT_ROOT "C:\Sites\example.org\htdocs" [...] C:\Sites\example.org>dir Volume in drive D is System Volume Serial Number is E49D-A2E7 Directory of C:\Sites\example.org 2010-05-31 01:08 . 2010-05-31 01:08 .. 2010-05-31 01:08 htdocs [C:\Repositories\example.org\trunk] You now run the script "C:\Sites\example.org\htdocs\test.php". Test script: --- http://bugs.php.net/bug.php?id=51952&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51952&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51952&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=51952&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=51952&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51952&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51952&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51952&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51952&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51952&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51952&r=support Expected behavior: http://bugs.php.net/fix.php?id=51952&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51952&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51952&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51952&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51952&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51952&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51952&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51952&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51952&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51952&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51952&r=mysqlcfg
#47800 [Bgs]: Sessions won't be loaded when Cookies are disabled
ID: 47800 User updated by: whistl0r+phpbug at googlemail dot com Reported By: whistl0r+phpbug at googlemail dot com Status: Bogus Bug Type: Session related Operating System: Windows PHP Version: 5.3.0RC1 New Comment: Please could you say at least why this is bogus? The example code is identical to your documentation, isn't it? http://www.php.net/manual/en/session.idpassing.php Did I miss a new behavior in PHP 5.3? Previous Comments: [2009-03-31 07:20:32] j...@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 [2009-03-27 02:36:36] whistl0r+phpbug at googlemail dot com Description: When forcing PHP to not use cookies for sessions, PHP isn't able to load an existing session. Instead it will create a new one. Tested with the default php.ini (php.ini-production) coming with the php-5.3.0RC1-nts-Win32-VC6-x86.zip package. I just fixed line 428 and set the session.save_path value. Session files will be created as expected. With PHP <5.3, the script is working as expected. I can confirm, that this problem is still present in the latest snapshot (VC6 x86 Thread Safe (2009-Mar-26 19:00:00)). Reproduce code: --- ' . PHP_EOL, $_SESSION['counter']); // Print Next link printf('Next', $_SERVER['PHP_SELF'], SID ); Expected result: When you first run this code, a session with a variable "counter" with the value "1" (int) should be created and a link pointing to the same script with this SESSION-ID should be displayed. When you click this link, you run this code again and the previous created session should be loaded and the "counter" variable should be incremented by 1. Actual result: -- On every run, PHP creates a new session. -- Edit this bug report at http://bugs.php.net/?id=47800&edit=1
#47834 [NEW]: tempnam() changes to %TEMP% instead of returning false
From: whistl0r+phpbug at googlemail dot com Operating system: Windows PHP version: 5.2.9 PHP Bug Type: Filesystem function related Bug description: tempnam() changes to %TEMP% instead of returning false Description: I wanted to check, how tempnam() handles file system limits. On NTFS, just 65535 files per directory are allowed. Reproduce code: --- http://bugs.php.net/?id=47834&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47834&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47834&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47834&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47834&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47834&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47834&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47834&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47834&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47834&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47834&r=support Expected behavior: http://bugs.php.net/fix.php?id=47834&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47834&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47834&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47834&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47834&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47834&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47834&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47834&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47834&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47834&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47834&r=mysqlcfg
#47800 [NEW]: Sessions won't be loaded when Cookies are disabled
From: whistl0r+phpbug at googlemail dot com Operating system: Windows PHP version: 5.3.0RC1 PHP Bug Type: Session related Bug description: Sessions won't be loaded when Cookies are disabled Description: When forcing PHP to not use cookies for sessions, PHP isn't able to load an existing session. Instead it will create a new one. Tested with the default php.ini (php.ini-production) coming with the php-5.3.0RC1-nts-Win32-VC6-x86.zip package. I just fixed line 428 and set the session.save_path value. Session files will be created as expected. With PHP <5.3, the script is working as expected. I can confirm, that this problem is still present in the latest snapshot (VC6 x86 Thread Safe (2009-Mar-26 19:00:00)). Reproduce code: --- ' . PHP_EOL, $_SESSION['counter']); // Print Next link printf('Next', $_SERVER['PHP_SELF'], SID ); Expected result: When you first run this code, a session with a variable "counter" with the value "1" (int) should be created and a link pointing to the same script with this SESSION-ID should be displayed. When you click this link, you run this code again and the previous created session should be loaded and the "counter" variable should be incremented by 1. Actual result: -- On every run, PHP creates a new session. -- Edit bug report at http://bugs.php.net/?id=47800&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47800&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47800&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47800&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47800&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47800&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47800&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47800&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47800&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47800&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47800&r=support Expected behavior: http://bugs.php.net/fix.php?id=47800&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47800&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47800&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47800&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47800&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47800&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47800&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47800&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47800&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47800&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47800&r=mysqlcfg