Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » protected/private access and var_dump/print_r »

protected/private access and var_dump/print_r

php.internals

Sara Golemon

22 years ago
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

Derick Rethans

22 years ago
On Mon, 17 May 2004, 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?
I think the current way is perfectly alright. regards, Derick

Andrey Hristov

22 years ago
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

Marcus Börger

22 years ago
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:helly@php.net

Andrey Hristov

22 years ago
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 <helly@php.net>:

Christian Schneider

22 years ago
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).
I agree with Derick and Andrey in that if anything should be changed it is var_dump. Reasoning: PPP is there to specify an interface, not to be used in a sandbox way. Both var_dump and print_r are for human inspection and I don't an advantage in hiding information there, quite the opposite. - Chris

Derick Rethans

22 years ago
On Tue, 18 May 2004, Christian Schneider 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). > > I agree with Derick and Andrey in that if anything should be changed it > is var_dump.
I don't want var_dump() to change. Derick

Christian Schneider

22 years ago
Derick Rethans wrote:
> I don't want var_dump() to change.
Oops, sorry for being too brief, I meant I agree with you about print_r being alright and like Andrey I think *if* something's changed it should be var_dump ;-) - Chris

Sara Golemon

22 years ago
> var_dump($someobject); shows only public properties (as I'd expect), but > print_r($someobject) shows all properties (explicitly identifying > protected/private props). >
So, to sum up the responses to the above question: 1) It's okay for print_r/var_dump to expose public/protected members (their access rights apply to the program, not the person) 2) print_r() shouldn't change a thing. 3) var_dump() *may* deserve a change to allow it to show private/protected props (There's an objection to this because....?...) Further would this qualify as a bugfix or more of a feature change? The next question that brings up then is in relation to bug#27798: I would think that get_object_vars() should expose private/protected props when called from within the class itself (as appropriate based on inheretance of course). Is this assumption true? -Sara

Derick Rethans

22 years ago
On Tue, 18 May 2004, Sara Golemon wrote:
> The next question that brings up then is in relation to bug#27798: > > I would think that get_object_vars() should expose private/protected props > when called from within the class itself (as appropriate based on > inheretance of course). Is this assumption true?
yeah, I think that's how it should work. Derick

Sara Golemon

22 years ago
> > The next question that brings up then is in relation to bug#27798: > > > > I would think that get_object_vars() should expose private/protected
props
> > when called from within the class itself (as appropriate based on > > inheretance of course). Is this assumption true? > > yeah, I think that's how it should work. >
Then how does this patch look: http://frankenbox.alphaweb.net/test/27798.diff With the following script: class A { public $a = 'A'; protected $b = 'B'; private $c = 'C'; function look_from_a() { echo "From A: "; var_dump( get_object_vars($this) ); } } class B extends A { function look_from_b() { echo "From B: "; var_dump( get_object_vars($this) ); } } $b = new B(); $b->look_from_a(); $b->look_from_b(); echo "From outside the objects: "; var_dump(get_object_vars($b)); It displays: From A: array(3) { ["a"]=> string(1) "A" ["b"]=> string(1) "B" ["c"]=> string(1) "C" } From B: array(2) { ["a"]=> string(1) "A" ["b"]=> string(1) "B" } From outside the objects: array(1) { ["a"]=> string(1) "A" } Everyone happy with that behavior? -Sara

Andi Gutmans

22 years ago
At 11:42 AM 5/18/2004 +0200, Christian Schneider 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). > >I agree with Derick and Andrey in that if anything should be changed it is >var_dump. > >Reasoning: PPP is there to specify an interface, not to be used in a >sandbox way. Both var_dump and print_r are for human inspection and I >don't an advantage in hiding information there, quite the opposite.
I agree that showing all PPP makes more sense for these functions. They are mainly debugging tools and for human inspection. Information hiding is important on the language level itself. Andi

Andrey Hristov

22 years ago
Andi Gutmans wrote:
> At 11:42 AM 5/18/2004 +0200, Christian Schneider 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). >> >> >> I agree with Derick and Andrey in that if anything should be changed >> it is var_dump. >> >> Reasoning: PPP is there to specify an interface, not to be used in a >> sandbox way. Both var_dump and print_r are for human inspection and I >> don't an advantage in hiding information there, quite the opposite. > > > I agree that showing all PPP makes more sense for these functions. They > are mainly debugging tools and for human inspection. Information hiding > is important on the language level itself. > > Andi >
So, I have made a patch against HEAD : http://hristov.com/andrey/projects/php_stuff/patches/var_dump.diff.2.txt php -r 'class a{ protected $a=1; private $b=2;var $c=3;} $a=new a(); var_dump($a);' produces : object(a)#1 (3) { ["a:protected"]=> int(1) ["b:private"]=> int(2) ["c"]=> int(3) } I hope that everyone will be happy with this. var_dump() is still BC since it does not print ":public" on public properties. Andrey

Andi Gutmans

22 years ago
Fine with me. I'm not sure printing public is a bad idea. How many ppl actually use this in their application for purposes other than debugging? At 09:28 AM 5/20/2004 +0200, Andrey Hristov wrote:

Derick Rethans

22 years ago
On Thu, 20 May 2004, Andi Gutmans wrote:
> Fine with me. I'm not sure printing public is a bad idea. How many ppl > actually use this in their application for purposes other than debugging?
Well, print_r doesn't print it either; so IMO if we add public here, we need to do that for print_r too. regards, Derick

Andi Gutmans

22 years ago
I'm OK with adding it to print_r() too if no one has any serious objections. At 12:04 PM 5/20/2004 +0200, Derick Rethans wrote:

Jan Schneider

22 years ago
Zitat von Andi Gutmans <andi@zend.com>:
> I'm OK with adding it to print_r() too if no one has any serious objections.
Perhaps only for members explicitely declared public, as opposed to var-style properties.
> At 12:04 PM 5/20/2004 +0200, Derick Rethans wrote: >> On Thu, 20 May 2004, Andi Gutmans wrote: >> >> > Fine with me. I'm not sure printing public is a bad idea. How many ppl >> > actually use this in their application for purposes other than debugging? >> >> Well, print_r doesn't print it either; so IMO if we add public here, we >> need to do that for print_r too. >> >> regards, >> Derick > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
Jan.
-- Do you need professional PHP or Horde consulting? http://horde.org/consulting.php

Derick Rethans

22 years ago
On Thu, 20 May 2004, Jan Schneider wrote:
> Zitat von Andi Gutmans <andi@zend.com>: > > > I'm OK with adding it to print_r() too if no one has any serious objections. > > Perhaps only for members explicitely declared public, as opposed to > var-style properties.
We can't distantiate between that. Derick

Sara Golemon

22 years ago
> >I hope that everyone will be happy with this. var_dump() is still BC
since
> >it does not print ":public" on public properties. > > > Fine with me. I'm not sure printing public is a bad idea. How many ppl > actually use this in their application for purposes other than debugging? >
I sure hope noone is, but worst case scenario (on protected/public) is that the variable name looks wrong to an application. Since they didn't have those to begin with it's not so-much taking anything away from them. On the patch: +1 As to printing :public on public props I'm -1 on that. There's no benefit from tacking on those extra characters and people are familiar with the current syntax. Besides, it's what print_r() has been doing for some time now so those that truly care have had an opporotunity to accomodate to that style. -Sara

Andrey Hristov

22 years ago
Sara Golemon wrote:
>>>I hope that everyone will be happy with this. var_dump() is still BC > > since > >>>it does not print ":public" on public properties. >>> >> >>Fine with me. I'm not sure printing public is a bad idea. How many ppl >>actually use this in their application for purposes other than debugging? >> > > I sure hope noone is, but worst case scenario (on protected/public) is that > the variable name looks wrong to an application. Since they didn't have > those to begin with it's not so-much taking anything away from them. > > On the patch: +1
Already commited
> > As to printing :public on public props I'm -1 on that. There's no benefit > from tacking on those extra characters and people are familiar with the > current syntax. Besides, it's what print_r() has been doing for some time > now so those that truly care have had an opporotunity to accomodate to that > style.
I have included in the patch the :public behaviour but now some testcases fail (they don't expect ":public" and also some does not expect private/protected variables to be dumped). So, what we decide, with :public or without it? I hope we can have a decision soon :) Andrey

Marcus Börger

22 years ago
Hello Andrey, Thursday, May 20, 2004, 8:15:41 PM, you wrote:
> Sara Golemon wrote: >>>>I hope that everyone will be happy with this. var_dump() is still BC >> >> since >> >>>>it does not print ":public" on public properties. >>>> >>> >>>Fine with me. I'm not sure printing public is a bad idea. How many ppl >>>actually use this in their application for purposes other than debugging? >>> >> >> I sure hope noone is, but worst case scenario (on protected/public) is that >> the variable name looks wrong to an application. Since they didn't have >> those to begin with it's not so-much taking anything away from them. >> >> On the patch: +1
> Already commited >> >> As to printing :public on public props I'm -1 on that. There's no benefit >> from tacking on those extra characters and people are familiar with the >> current syntax. Besides, it's what print_r() has been doing for some time >> now so those that truly care have had an opporotunity to accomodate to that >> style.
> I have included in the patch the :public behaviour but now some testcases fail (they don't > expect ":public" and also some does not expect private/protected variables to be dumped). > So, what we decide, with :public or without it? I hope we can have a decision soon :)
What ever we decide i suggest you fix the errors now - it may take a while until we have decided and a lot of failing tests is very bad. Best regards, Marcus mailto:helly@php.net