#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=28155edit=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=29271edit=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=29271edit=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=29271edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29271r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29271r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29271r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29271r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29271r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29271r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29271r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29271r=support
Expected behavior: http://bugs.php.net/fix.php?id=29271r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29271r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29271r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29271r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29271r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29271r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29271r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29271r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29271r=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=29191edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29191r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29191r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29191r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29191r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29191r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29191r=needscript Try newer version: http://bugs.php.net/fix.php?id=29191r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29191r=support Expected behavior: http://bugs.php.net/fix.php?id=29191r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29191r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29191r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29191r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29191r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29191r=dst IIS Stability: http://bugs.php.net/fix.php?id=29191r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29191r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29191r=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
?
header( 'WWW-Authenticate: Basic realm=WG Content-Management' );
?
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=29129edit=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:
?php
$array = new ArrayObject();
$array-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:
?php
$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:
?php
$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);
?
[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=28831edit=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:
?php
$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:
?php
$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);
?
[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=28831edit=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=28831edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28831r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28831r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28831r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28831r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28831r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28831r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28831r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28831r=support
Expected behavior: http://bugs.php.net/fix.php?id=28831r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28831r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28831r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28831r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28831r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28831r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28831r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28831r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28831r=float
#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 [ internal:SPL iterateable 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 [ internal:SPL iterateable class ArrayIterator implements
Iterator, Traversable, ArrayAccess, SeekableIterator ] {
.
Method [ internal 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=28813edit=1
#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=28814edit=1
#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=28822edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28822r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28822r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28822r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28822r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28822r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28822r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28822r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28822r=support
Expected behavior: http://bugs.php.net/fix.php?id=28822r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28822r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28822r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28822r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28822r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28822r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28822r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28822r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28822r=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=28813edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28813r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28813r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28813r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28813r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28813r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28813r=needscript Try newer version: http://bugs.php.net/fix.php?id=28813r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28813r=support Expected behavior: http://bugs.php.net/fix.php?id=28813r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28813r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28813r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28813r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28813r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28813r=dst IIS Stability: http://bugs.php.net/fix.php?id=28813r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28813r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28813r=float
#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=28814edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28814r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28814r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28814r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28814r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28814r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28814r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28814r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28814r=support
Expected behavior: http://bugs.php.net/fix.php?id=28814r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28814r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28814r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28814r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28814r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28814r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28814r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28814r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28814r=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 'a href=/?' . SID . 'Bug/a: ' . $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=26099edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26099r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26099r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26099r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26099r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26099r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26099r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26099r=support
Expected behavior: http://bugs.php.net/fix.php?id=26099r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26099r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26099r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26099r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26099r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26099r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26099r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26099r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26099r=float
