Hallo Marcus, then will you cut the protected/private functionality from print_r() (so the engine). Probably not :) . IMO var_dump() has been always superior for usage to print_r(). During his presentation at the last conference Derick had to change print_r() in his example to var_dump() to show that for example some function returns NULL. And as I mentioned Andrei also thought that we have to add the functionality to var_dump(). And we know that private/protected member variables can be read : php -r 'class fubar {private $priv_prop=1;} $a=new fubar();var_dump((array) $a);'
Gruesse, Andrey Quoting Marcus Boerger <[EMAIL PROTECTED]>: > Hello Andrey, > > if we change something then we prevent all those function from showing > private and protected values. The current situation is ok for me though. > > marcus > > Tuesday, May 18, 2004, 10:01:12 AM, you wrote: > > > Sara Golemon wrote: > >> var_dump($someobject); shows only public properties (as I'd expect), but > >> print_r($someobject) shows all properties (explicitly identifying > >> protected/private props). > >> > >> Am I wrong in thinking that's not right? > >> > >> -Sara > >> > > print_r relies on a engine's routine while var_dump() does not. I had a > patch to enable > > var_dump do dump also the protected/private stuff (since I am var_dump() > not a print_r() > > fan). AFAIR Andrei was pro for var_dump() being consistent with print_r(). > > > http://www.hristov.com/andrey/projects/php_stuff/patches/var_dump.diff > > > The patch is from August last year. AFAIR it does what's expected :) > > > Andrey > > > > > -- > Best regards, > Marcus mailto:[EMAIL PROTECTED] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php