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

Reply via email to