Re: Object to array conversion oddity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Saturday 23 September 2006 11:41, Marcus Bointon wrote:
> On 23 Sep 2006, at 16:46, Robert Cummings wrote:
> > And the likelihood of you having a property called Myclassfield1 is?
>
> Sure, but don't you think that coding should at least try to be
> driven by logic rather than luck? I'm also not denying that it's not
> too hard to work around (with a function not dissimilar to what you
> suggested), but I'd really prefer it if it just did what it says on
> the tin. By its very nature, casting from object to array indicates
> that you no longer want the constraints of property protection, which
> an array can't preserve anyway, and it's not as if there are not
> intentional, documented methods of obtaining this information.
>
> > It sounds like they've helped out by giving more data than was
> > necessary.
>
> ...and in doing so defaults to breaking code that expects it to
> behave like the documentation says it does? I don't think I'd
> classify that as helping out. Bear in mind that my code broke in
> exactly this way. If you want to find out what the access level of a
> property is, I doubt your first thought would be to convert it to an
> array - and I bet you didn't know that this info was even there
> because it's not documented, thus helping nobody. This is what
> introspection is for. I don't have a problem with being provided with
> extra information, just as long as it doesn't interfere with correct
> operation, which is what it currently does. It could provide the
> extra info in a marginally less destructive way, for example by
> adding 'private' and 'protected' array properties containing field
> names for each access level to the resulting array. OTOH, that would
> break what you'd expect count() to deliver after the conversion. I
> really think it should just do what's it's meant to, and no more.
>
> Marcus

You're right about the undocumented feature that you ran into.  It did not 
behave the way the documentation pointed it out, and either the documentation 
or the behavior needs to be modified.

I would guess that modification of the behavior might take a while to come 
out, unless you were going to patch your install, but even then it might be a 
while.  So, to get around that you could create a function to "convert" the 
array to what you expected.  Here's a possible declaration:

function convertClassArray($array, $className)

That function would then create a new array and change the keys as necessary, 
stripping off the class name from the private variables and stripping off the 
* from the protected ones, to give you what you expected.  Not exactly what 
you're looking for, but it would probably help to keep the changes to your 
existing code down while you're waiting for a patch/documentation change.

-- 
Ray Hauge
Programmer/Systems Administrator
American Student Loan Services
www.americanstudentloan.com
1.800.575.1099

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux