| marcus at synchromedia dot co dot uk 2006-09-25, 6:57 pm |
| ID: 38935
User updated by: marcus at synchromedia dot co dot uk
Reported By: marcus at synchromedia dot co dot uk
Status: Analyzed
Bug Type: Documentation problem
Operating System: All
PHP Version: 5.1.6
New Comment:
OK, Thanks for dealing with it.
Previous Comments:
------------------------------------------------------------------------
[2006-09-25 21:25:44] joey@php.net
We won't mark as closed until the doc patch has actually
been submitted (currently in review).
------------------------------------------------------------------------
[2006-09-25 21:20:07] marcus at synchromedia dot co dot uk
It turns out that this was actually a documentation problem,
and apparently a fix has been posted in docs. So, the
'strange' entries are intentional, and the new docs will
explain them.
------------------------------------------------------------------------
[2006-09-23 18:27:20] marcus at synchromedia dot co dot uk
Well, that's good to know, but it does mean that you're
justifying undocumented behaviour with yet more undocumented
behaviour.
I see that these null bytes are there, but they're not
separators; they're prefixes to both class and property
name, that is, the resulting array keys are of the form:
NULL<classname>NULL<propertyname>
I still fail to see how this is bogus when it's so wildly
different to what's documented, and is implemented in such a
way as to be useful in only the most obtuse of situations,
to the detriment of all other occasions. One change that
would make all this much more palatable while preserving the
additional information AND conforming closer to the docs:
only provide extended class information for properties that
are NOT in the current class. For example:
<?php
class A {
private $A;
}
class B extends A {
private $A;
public $B;
}
$a = (array)new B;
foreach($a as $k => $v) {
echo bin2hex($k)."\n";
}
?>
At present this produces:
00420041
00410041
My suggestion is to change that to:
00420041
41
That way we will be in the situation that all unambiguous
properties in the current class are available using their
unmodified names, just like the docs say. The only remaining
issue is with protected values - I don't know that
preserving that status is of much value anyway - it's not as
if you can cast back from an array to an object anyway.
------------------------------------------------------------------------
[2006-09-23 17:34:44] mike@php.net
There are separators, null bytes.
------------------------------------------------------------------------
[2006-09-23 16:39:22] marcus at synchromedia dot co dot uk
I'm sorry but that's a bogus explanation. "Please double-
check the documentation"? What you describe is contrary to
the documentation.
The reasoning you express also fails completely on my point
about there being no separator between class name and
property name. How can you consider this to be reasonable
behaviour?:
class A {
private $A;
}
class B extends A {
private $A;
public $AA;
}
var_dump((array)new B());
array(3) {
["BA"]=>
NULL
["AA"]=>
NULL
["AA"]=>
NULL
}
Given that this undocumented behaviour is thus proven
ambiguous, unreliable and contrary to existing docs, how can
you say that it's 'needed'? Are you saying that there's
widespread code that depends on this weirdness, when 99% of
use cases will not expect it?
At the very least this is a valid documentation bug.
------------------------------------------------------------------------
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/38935
--
Edit this bug report at http://bugs.php.net/?id=38935&edit=1
|