On 23 Sep 2006, at 18:54, Jon Anderson wrote:
If you just want an array of properties, add this to your class...
That's exactly the kind of thing I was on about. Since reflection
gives access to all this information, why bother trying to squeeze
the same info into an array-shaped container that just can't hold all
the same info without corrupting it? I can see that there might be
some reason for converting the object with additional information in
some circumstances (much like serialization to strings does), but
here we're only talking about casting, which should be a 'best-fit'
data matter. The behaviour we've got would be better served with a
function like toArrayPreservingClassInfo() rather than the default
casting behaviour.
Since reporting the bug (which was immediately marked as bogus; go
figure), I've had something else brought to my attention: The
resulting array keys are not what they seem! Their actual structure is:
NULL<classname>NULL<propertyname>
So, here we have undocumented behaviour justified by yet more
undocumented behaviour! How behaviour so wildly different to what's
documented is not considered a bug I don't know. At least this format
can be dismantled reliably, rather than trying to string-match class
names. I think trying to preserve this information (as you said) is
entirely pointless - it's not as if you can cast back from an array
to an object, and I can't think of any circumstances in which it is
preferable to using reflection (unless it's a relic from PHP4?).
What's next - appending a creation time to integers when they're cast
into strings?
Marcus
--
Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
marcus@xxxxxxxxxxxxxxxxxx | http://www.synchromedia.co.uk/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
