#28155 [Com]: clone reserved word? T_CLONE parse error
ID: 28155 Comment by: nospam0 at malkusch dot de Reported By: fbn79 at libero dot it Status: Bogus Bug Type: Zend Engine 2 problem Operating System: winxp pro PHP Version: 5CVS-2004-04-26 (dev) New Comment: How about turning the keyword off, when zend.ze1_compatibility_mode is used? There might be some PHP4 classes (and I had one of them) which have a clone method and are broken since PHP5. Previous Comments: [2004-06-03 11:05:12] ben at jazzyphones dot com Hi I am getting the same behaviour but am not sure how to fix this based on the above comments. You say you have updated the summary, can you link to this summary? Regards [2004-04-26 16:46:03] [EMAIL PROTECTED] Updated summary to make it easier to find for other people running into this new behavior. [2004-04-26 16:45:09] [EMAIL PROTECTED] It's a keyword now, and not a bug (As it's expected behavior) [2004-04-26 14:02:38] fbn79 at libero dot it Description: I'm not sure if it's a buf or if the function name "clone" was reserved in php5. The parse errore exist in RC1 and RC2 whith or without Compatibility Mode OFF or ON Reproduce code: --- class myclass{ function &clone() { } } Actual result: -- Parse error: parse error, unexpected T_CLONE, expecting T_STRING in ... on line ... -- Edit this bug report at http://bugs.php.net/?id=28155&edit=1
#29271 [Bgs]: behaviour of $string['text'] = 'new string';
ID: 29271 User updated by: nospam0 at malkusch dot de Reported By: nospam0 at malkusch dot de Status: Bogus Bug Type: Strings related Operating System: * PHP Version: 5.0.0 New Comment: > $string already IS a string and you still can use > array-brackets to access a particular symbol So PHP will never throw an error, even [] on strings is deprecated since PHP4? Previous Comments: [2004-07-28 13:25:55] [EMAIL PROTECTED] $string already IS a string and you still can use array-brackets to access a particular symbol, so it won't become an array. [2004-07-28 13:15:34] nospam0 at malkusch dot de > It's expected behaviour: 'index' is casted to it's > integer value (0), that's why you get this result. But as I use $string[] and not $string{} it's undefined wether it should be a new array or a string. So why doesn't PHP throw an error? [2004-07-28 12:39:59] [EMAIL PROTECTED] 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 It's expected behaviour: 'index' is casted to it's integer value (0), that's why you get this result. -------------------- [2004-07-20 01:54:22] nospam0 at malkusch dot de Description: $string = 'a bla'; $string['index'] = 'b blub'; does the same work as $string = 'a bla'; $string{(int)'index'} = 'b blub'{0}; without any notic of undefined index or too long replacing string. But it should throw any notice, because one could expect that the code should produce a new Array('index' => 'b blubb'). Reproduce code: --- $string = 'a bla'; $string['index'] = 'b blub'; var_dump($string); Expected result: Either notices for use of deprecated [], undefined offset 'index' and too long replace char (and of course the actual result) or 'a bla' is deleted and $string has array('index' => 'b blubb') as value. Actual result: -- string(5) "b bla" -- Edit this bug report at http://bugs.php.net/?id=29271&edit=1
#29271 [Bgs]: behaviour of $string['text'] = 'new string';
ID: 29271 User updated by: nospam0 at malkusch dot de Reported By: nospam0 at malkusch dot de Status: Bogus Bug Type: Strings related Operating System: * PHP Version: 5.0.0 New Comment: > It's expected behaviour: 'index' is casted to it's > integer value (0), that's why you get this result. But as I use $string[] and not $string{} it's undefined wether it should be a new array or a string. So why doesn't PHP throw an error? Previous Comments: [2004-07-28 12:39:59] [EMAIL PROTECTED] 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 It's expected behaviour: 'index' is casted to it's integer value (0), that's why you get this result. ---------------- [2004-07-20 01:54:22] nospam0 at malkusch dot de Description: $string = 'a bla'; $string['index'] = 'b blub'; does the same work as $string = 'a bla'; $string{(int)'index'} = 'b blub'{0}; without any notic of undefined index or too long replacing string. But it should throw any notice, because one could expect that the code should produce a new Array('index' => 'b blubb'). Reproduce code: --- $string = 'a bla'; $string['index'] = 'b blub'; var_dump($string); Expected result: Either notices for use of deprecated [], undefined offset 'index' and too long replace char (and of course the actual result) or 'a bla' is deleted and $string has array('index' => 'b blubb') as value. Actual result: -- string(5) "b bla" -- Edit this bug report at http://bugs.php.net/?id=29271&edit=1
#29271 [NEW]: behaviour of $string['text'] = 'new string';
From: nospam0 at malkusch dot de Operating system: * PHP version: 5.0.0 PHP Bug Type: Strings related Bug description: behaviour of $string['text'] = 'new string'; Description: $string = 'a bla'; $string['index'] = 'b blub'; does the same work as $string = 'a bla'; $string{(int)'index'} = 'b blub'{0}; without any notic of undefined index or too long replacing string. But it should throw any notice, because one could expect that the code should produce a new Array('index' => 'b blubb'). Reproduce code: --- $string = 'a bla'; $string['index'] = 'b blub'; var_dump($string); Expected result: Either notices for use of deprecated [], undefined offset 'index' and too long replace char (and of course the actual result) or 'a bla' is deleted and $string has array('index' => 'b blubb') as value. Actual result: -- string(5) "b bla" -- Edit bug report at http://bugs.php.net/?id=29271&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29271&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29271&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29271&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29271&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29271&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29271&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29271&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29271&r=support Expected behavior: http://bugs.php.net/fix.php?id=29271&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29271&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29271&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29271&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29271&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29271&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29271&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29271&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29271&r=float
#29191 [NEW]: throwing Exceptions instead of printing error messages
From: nospam0 at malkusch dot de Operating system: * PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: throwing Exceptions instead of printing error messages Description: It would be nice if the native methods would throw exceptions instead of printing error messages. It seems more consequent (and easier to handle) as PHP has exceptions. At least the native classes could do this. For compatibility reasons it can depend on zend.ze1_compatibility_mode or a new configuration directive. At the moment I have to wrap every method and class in order to work properly with exceptions. -- Edit bug report at http://bugs.php.net/?id=29191&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29191&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29191&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29191&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29191&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29191&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29191&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29191&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29191&r=support Expected behavior: http://bugs.php.net/fix.php?id=29191&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29191&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29191&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29191&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29191&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29191&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29191&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29191&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29191&r=float
#29129 [Com]: PHP_AUTH_USER does not seem to be passing thru
ID: 29129 Comment by: nospam0 at malkusch dot de Reported By: sethw at webglimmer dot com Status: Open Bug Type: *General Issues Operating System: Linux RH ES 3.0 PHP Version: 5.0.0 New Comment: In fact it is set, but it's NULL (use array_key_exists() instead of isset()). I have the same problem with PHP5 final. CVS from 8th Juli works fine. Previous Comments: [2004-07-14 10:42:04] alex dot pagnoni at solarix dot it Same bug as #29132. [2004-07-14 01:56:33] sethw at webglimmer dot com Description: So a dump of $_SERVER reveals that after a that $_SERVER['PHP_AUTH_PW'] is set but not $_SERVER['PHP_AUTH_USER'] Any ideas? Reproduce code: --- if (isset( $_SERVER['PHP_AUTH_USER'] ) && isset($_SERVER['PHP_AUTH_PW'])) { // code } // always returns false regardless of what is entered Expected result: should return true if the "Authentication Box" is filled in -- Edit this bug report at http://bugs.php.net/?id=29129&edit=1
#28831 [Bgs->Opn]: ArrayObject::offsetGet() does the work of offsetUnset()
ID: 28831 User updated by: nospam0 at malkusch dot de -Summary: ArrayObject::offsetGet() does not return a stored ArrayObject Reported By: nospam0 at malkusch dot de -Status: Bogus +Status: Open Bug Type: Arrays related Operating System: * PHP Version: 5.0.* Assigned To: helly New Comment: > Returning "not a reference" = "creating a copy". That's > why. That's why offsetGet deletes the entry? Perhaps you didn't get what I mean and actually the subject for this bug is wrong, so I changed it (Sorry I was fixed on the 2D ArrayObject). Try: append('test'); var_dump($array); $array->offsetGet(0); var_dump($array); ?> It will return object(ArrayObject)#1 (1) { [0]=> string(4) "test" } object(ArrayObject)#1 (1) { [0]=> NULL } So, In my eyes it is a bug, that offsetGet deletes the entry from the ArrayObject. It should return a copy (or better a reference) and not touch the ArrayObject. Previous Comments: [2004-06-20 11:44:18] [EMAIL PROTECTED] Returning "not a reference" = "creating a copy". That's why. Hopefully we are able to return references in 5.1 so we can solve this then ------------ [2004-06-20 05:19:38] nospam0 at malkusch dot de > Try this code: > > $array = new ArrayObject(); > $subArray = new ArrayObject(); > $array->append($subArray); > > $subArray->append(\'item\'); > var_dump($array); > > $x=$array->offsetGet(0); > $x->append(\'item2\'); > var_dump($array); > var_dump($x); > > ?> I don't think, that the output is expected: object(ArrayObject)#1 (1) { [0]=> object(ArrayObject)#2 (1) { [0]=> string(4) "item" } } object(ArrayObject)#1 (1) { [0]=> NULL } object(ArrayObject)#2 (2) { [0]=> string(4) "item" [1]=> string(5) "item2" } Why is there a NULL in the second var_dump? If offsetGet() would not return a reference I would at least expect, that my ArrayObject won't loose its entry. It seems that offsetGet() does the work of offsetUnset(). [2004-06-18 20:55:21] [EMAIL PROTECTED] 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 Unfortunatley internal functions cannot return a reference... Try this code: append($subArray); $subArray->append(\'item\'); var_dump($array); $x=$array->offsetGet(0); $x->append(\'item2\'); var_dump($array); var_dump($x); ?> [2004-06-18 16:19:13] nospam0 at malkusch dot de Description: If I save an ArrayObject in an ArrayObject, I can't manipulate the stored ArrayObject, by getting it with offsetGet() Reproduce code: --- $array = new ArrayObject(); $subArray = new ArrayObject(); $array->append($subArray); $subArray->append('item'); var_dump($array); $array->offsetGet(0)->append('item2'); var_dump($array); Expected result: object(ArrayObject)#23 (1) { [0]=> object(ArrayObject)#24 (1) { [0]=> string(4) "item" } } oobject(ArrayObject)#23 (1) { [0]=> object(ArrayObject)#24 (1) { [0]=> string(4) "item", [1]=> string(5) "item2" } } Actual result: -- object(ArrayObject)#23 (1) { [0]=> object(ArrayObject)#24 (1) { [0]=> string(4) "item" } } object(ArrayObject)#23 (1) { [0]=> NULL } -- Edit this bug report at http://bugs.php.net/?id=28831&edit=1
#28831 [Bgs]: ArrayObject::offsetGet() does not return a stored ArrayObject
ID: 28831 User updated by: nospam0 at malkusch dot de Reported By: nospam0 at malkusch dot de Status: Bogus Bug Type: Arrays related Operating System: Linux PHP Version: 5CVS-2004-06-18 (dev) New Comment: > Try this code: > > $array = new ArrayObject(); > $subArray = new ArrayObject(); > $array->append($subArray); > > $subArray->append(\'item\'); > var_dump($array); > > $x=$array->offsetGet(0); > $x->append(\'item2\'); > var_dump($array); > var_dump($x); > > ?> I don't think, that the output is expected: object(ArrayObject)#1 (1) { [0]=> object(ArrayObject)#2 (1) { [0]=> string(4) "item" } } object(ArrayObject)#1 (1) { [0]=> NULL } object(ArrayObject)#2 (2) { [0]=> string(4) "item" [1]=> string(5) "item2" } Why is there a NULL in the second var_dump? If offsetGet() would not return a reference I would at least expect, that my ArrayObject won't loose its entry. It seems that offsetGet() does the work of offsetUnset(). Previous Comments: [2004-06-18 20:55:21] [EMAIL PROTECTED] 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 Unfortunatley internal functions cannot return a reference... Try this code: append($subArray); $subArray->append(\'item\'); var_dump($array); $x=$array->offsetGet(0); $x->append(\'item2\'); var_dump($array); var_dump($x); ?> [2004-06-18 16:19:13] nospam0 at malkusch dot de Description: If I save an ArrayObject in an ArrayObject, I can't manipulate the stored ArrayObject, by getting it with offsetGet() Reproduce code: --- $array = new ArrayObject(); $subArray = new ArrayObject(); $array->append($subArray); $subArray->append('item'); var_dump($array); $array->offsetGet(0)->append('item2'); var_dump($array); Expected result: object(ArrayObject)#23 (1) { [0]=> object(ArrayObject)#24 (1) { [0]=> string(4) "item" } } oobject(ArrayObject)#23 (1) { [0]=> object(ArrayObject)#24 (1) { [0]=> string(4) "item", [1]=> string(5) "item2" } } Actual result: -- object(ArrayObject)#23 (1) { [0]=> object(ArrayObject)#24 (1) { [0]=> string(4) "item" } } object(ArrayObject)#23 (1) { [0]=> NULL } -- Edit this bug report at http://bugs.php.net/?id=28831&edit=1
#28831 [NEW]: ArrayObject::offsetGet() does not return a stored ArrayObject
From: nospam0 at malkusch dot de Operating system: Linux PHP version: 5CVS-2004-06-18 (dev) PHP Bug Type: Arrays related Bug description: ArrayObject::offsetGet() does not return a stored ArrayObject Description: If I save an ArrayObject in an ArrayObject, I can't manipulate the stored ArrayObject, by getting it with offsetGet() Reproduce code: --- $array = new ArrayObject(); $subArray = new ArrayObject(); $array->append($subArray); $subArray->append('item'); var_dump($array); $array->offsetGet(0)->append('item2'); var_dump($array); Expected result: object(ArrayObject)#23 (1) { [0]=> object(ArrayObject)#24 (1) { [0]=> string(4) "item" } } oobject(ArrayObject)#23 (1) { [0]=> object(ArrayObject)#24 (1) { [0]=> string(4) "item", [1]=> string(5) "item2" } } Actual result: -- object(ArrayObject)#23 (1) { [0]=> object(ArrayObject)#24 (1) { [0]=> string(4) "item" } } object(ArrayObject)#23 (1) { [0]=> NULL } -- Edit bug report at http://bugs.php.net/?id=28831&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28831&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28831&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28831&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28831&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28831&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28831&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28831&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28831&r=support Expected behavior: http://bugs.php.net/fix.php?id=28831&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28831&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28831&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28831&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28831&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28831&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28831&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28831&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28831&r=float
#28822 [NEW]: ArrayObject::offsetExists() works inverted
From: nospam0 at malkusch dot de Operating system: Linux PHP version: 5.0.0RC3 PHP Bug Type: Arrays related Bug description: ArrayObject::offsetExists() works inverted Description: Hi IMO offsetExists() should return true, if a key exists and false if not. But it does it inverted. Reproduce code: --- $array = new ArrayObject(); $array->offsetSet('key', 'value'); var_dump($array->offsetExists('key')); var_dump($array->offsetExists('nokey')); Expected result: bool(true) bool(false) Actual result: -- bool(false) bool(true) -- Edit bug report at http://bugs.php.net/?id=28822&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28822&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28822&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28822&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28822&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28822&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28822&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28822&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28822&r=support Expected behavior: http://bugs.php.net/fix.php?id=28822&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28822&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28822&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28822&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28822&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28822&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28822&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28822&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28822&r=float
#28814 [Bgs]: class type hints for function parameters to not allow the passing of NULL
ID: 28814 User updated by: nospam0 at malkusch dot de Reported By: nospam0 at malkusch dot de Status: Bogus Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.0.0RC3 New Comment: > - Typhints are a shortcut for an 'instanceof' test. I'll never use instanceOf in any OO Language. It's sign for a bad design. > - what you probably want is > function bla($x) { > if (is_null($x)) { >// handle null > } else if ($x instanceof whatever) { >// handle instance > } else { >// handle error > } > } > > - if you look again you\'ll see that you are doing > *three different* things in your code. I don't want that. I want for example this: class Node { private $parent; private $children = array(); public function setParent(Node $node) { $this->parent = $node; } public function removeChild($childID) { $this->children[$childID]->setParent(NULL); unset($this->children[$childID]); } ... } Or I simply want to have the possibility to use optional Paramters and Type Hints: class Foo { public function setDate(Date $date = NULL) { if (is_null($date)) { $date = new Date(time()); } ... } > Typehints have a different usage! The please tell me what usage they have! I thaught they might bring PHP nearer to an strict language, but if I have to do without NULL or the possibility to use optional Parameters I can't use Type Hints strictly. By the way in Java, OCL (and C++ I think too), NULL can be passed as any Type. Previous Comments: [2004-06-17 09:40:24] [EMAIL PROTECTED] 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 - NOTHING stops you from passing NULL to functions. - Typhints are a shortcut for an \'instanceof\' test. - now try NULL instanceof stdclass: php-cvs $ php -r \'var_dump(NULL instanceof stdclass);\' bool(false) - what you probably want is function bla($x) { if (is_null($x)) { // handle null } else if ($x instanceof whatever) { // handle instance } else { // handle error } } - if you look again you\'ll see that you are doing *three different* things in your code. Typehints have a different usage! -------- [2004-06-17 05:48:33] nospam0 at malkusch dot de Description: Since RC3 I can't define optional parameters when I'm using type hinting. Why is it no more allowed to use NULL. Im used to do so from other OO Languages. So if I have to live with no NULL and want to use class Type hints, how can I use optional Paramters? Reproduce code: --- class Test { public function test(Test $optinalTest = null) { } } Expected result: No Error, or a possibility to use class type hints *and* optinal parameters. Perfect would be the old behavoir, that I'm allowed to use NULL. Actual result: -- Fatal error: Argument 1 must not be null -- Edit this bug report at http://bugs.php.net/?id=28814&edit=1
#28813 [Bgs]: ArrayObject should implement IteratorAggregate
ID: 28813 User updated by: nospam0 at malkusch dot de Reported By: nospam0 at malkusch dot de Status: Bogus Bug Type: Feature/Change Request Operating System: * PHP Version: 5.0.0RC3 New Comment: Yes, when I'm using ReflectionAPI I see that I'm wrong. I thaught, that an Iterator must have a hasMore() method...But it is the valid() method. I don't know where I have that wrong information from. Previous Comments: [2004-06-17 09:37:33] [EMAIL PROTECTED] 1) It does: php -r 'ReflectionClass::export("ArrayObject");' Class [ class ArrayObject implements IteratorAggregate, Traversable, ArrayAccess ] { .. 2) The base interface for ALL Iterators is Traversable 3) The iterators all serve different purposes. 4) ArrayIterator has a method valid(), otherwise it couldn't implement Iterator: php -r 'ReflectionClass::export("ArrayIterator");' Class [ class ArrayIterator implements Iterator, Traversable, ArrayAccess, SeekableIterator ] { . Method [ public method valid ] { } . => There is obviously nothing to change. Next time you file a bug report verify what you propose. ---------------- [2004-06-17 05:39:14] nospam0 at malkusch dot de Description: It would be very nice, if the ArrayObject would implement IteratorAggregate. The only thing, which must be done, is ArrayIterator should implement Iterator, by aliasing valid() with hasMore(). I think it's to confusing to use so many different Iterators wich all provides the same functionallity of Iterator. So why don't they all extend Iterator? -- Edit this bug report at http://bugs.php.net/?id=28813&edit=1
#28814 [NEW]: class type hints for function parameters to not allow the passing of NULL
From: nospam0 at malkusch dot de Operating system: Linux PHP version: 5.0.0RC3 PHP Bug Type: Feature/Change Request Bug description: class type hints for function parameters to not allow the passing of NULL Description: Since RC3 I can't define optional parameters when I'm using type hinting. Why is it no more allowed to use NULL. Im used to do so from other OO Languages. So if I have to live with no NULL and want to use class Type hints, how can I use optional Paramters? Reproduce code: --- class Test { public function test(Test $optinalTest = null) { } } Expected result: No Error, or a possibility to use class type hints *and* optinal parameters. Perfect would be the old behavoir, that I'm allowed to use NULL. Actual result: -- Fatal error: Argument 1 must not be null -- Edit bug report at http://bugs.php.net/?id=28814&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28814&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28814&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28814&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28814&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28814&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28814&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28814&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28814&r=support Expected behavior: http://bugs.php.net/fix.php?id=28814&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28814&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28814&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28814&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28814&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28814&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28814&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28814&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28814&r=float
#28813 [NEW]: ArrayObject should implement IteratorAggregate
From: nospam0 at malkusch dot de Operating system: Linux PHP version: 5.0.0RC3 PHP Bug Type: Feature/Change Request Bug description: ArrayObject should implement IteratorAggregate Description: It would be very nice, if the ArrayObject would implement IteratorAggregate. The only thing, which must be done, is ArrayIterator should implement Iterator, by aliasing valid() with hasMore(). I think it's to confusing to use so many different Iterators wich all provides the same functionallity of Iterator. So why don't they all extend Iterator? -- Edit bug report at http://bugs.php.net/?id=28813&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28813&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28813&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28813&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28813&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28813&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28813&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28813&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28813&r=support Expected behavior: http://bugs.php.net/fix.php?id=28813&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28813&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28813&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28813&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28813&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28813&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28813&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28813&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28813&r=float
#26099 [NEW]: session is not available in __destruct()
From: nospam0 at malkusch dot de Operating system: Linux PHP version: 5.0.0b1 (beta1) PHP Bug Type: Session related Bug description: session is not available in __destruct() Description: Actually I'm talking about beta2 of PHP5, but it wasn't listed. I think the __destruct() method should do things like cleaning up any resources. So it would be nice if I could destroy Sessions which are empty. But the Session Handler for closing the Session is called before the __destruct() methods. Reproduce code: --- class Bug { private $i = 0; public function __construct() { session_start(); if ( isset( $_SESSION['i'] ) ) { $this->i = $_SESSION['i']; } $this->i ++; $_SESSION['i'] = $this->i; } public function printLink() { echo 'Bug: ' . $this->i; } public function __destruct() { if ( $this->i > 4 ) { session_destroy(); } } } $bug = new Bug(); $bug->printLink(); Expected result: I would expect that the Session is still active and can be manipulated in any __destruct() method. Actual result: -- PHP's Session Handler for closing the Session is called before any __destruct method. So I can't do anything with the Session in the __destruct method. -- Edit bug report at http://bugs.php.net/?id=26099&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26099&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26099&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26099&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26099&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26099&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26099&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26099&r=support Expected behavior: http://bugs.php.net/fix.php?id=26099&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26099&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26099&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26099&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26099&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26099&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26099&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26099&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26099&r=float