# protected/private access and var_dump/print_r

- Thread: https://externals.io/message/9925
- Original archive: https://news-web.php.net/php.internals/9925
- Started by Sara Golemon on 2004-05-18T04:01:42+00:00
- Messages: 13
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #9925 — Sara Golemon — 2004-05-18T04:01:42+00:00

URL: https://externals.io/message/9925#9925

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

---

## #9927 — Derick Rethans — 2004-05-18T07:47:29+00:00

URL: https://externals.io/message/9925#9927 · In reply to: #9925

> 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

---

## #9928 — Andrey Hristov — 2004-05-18T08:01:12+00:00

URL: https://externals.io/message/9925#9928 · In reply to: #9925

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

---

## #9929 — Marcus Boerger — 2004-05-18T08:06:51+00:00

URL: https://externals.io/message/9925#9929 · In reply to: #9928

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:
> > […]
> 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

---

## #9931 — Christian Schneider — 2004-05-18T09:42:02+00:00

URL: https://externals.io/message/9925#9931 · In reply to: #9925

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

---

## #9932 — Derick Rethans — 2004-05-18T09:46:50+00:00

URL: https://externals.io/message/9925#9932 · In reply to: #9931

> Sara Golemon wrote:
> > […]
>
> 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

---

## #9933 — Christian Schneider — 2004-05-18T10:01:42+00:00

URL: https://externals.io/message/9925#9933 · In reply to: #9932

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

---

## #9934 — Andrey Hristov — 2004-05-18T10:13:00+00:00

URL: https://externals.io/message/9925#9934 · In reply to: #9929

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>:

> 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:
>
> > […]
> patch to enable
> > […]
> not a `print_r()`
> > […]
>
> > […]
>
> > […]
>
> > […]
>
>
>
>
> --
> Best regards,
>  Marcus                            mailto:helly@php.net

---

## #9943 — Sara Golemon — 2004-05-18T14:32:27+00:00

URL: https://externals.io/message/9925#9943 · In reply to: #9925

> 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

---

## #9944 — Derick Rethans — 2004-05-18T14:42:56+00:00

URL: https://externals.io/message/9925#9944 · In reply to: #9943

> 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

---

## #9946 — Sara Golemon — 2004-05-18T20:00:05+00:00

URL: https://externals.io/message/9925#9946 · In reply to: #9944

> > […]
props
> > […]
>
> 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

---

## #9950 — Andi Gutmans — 2004-05-19T12:25:43+00:00

URL: https://externals.io/message/9925#9950 · In reply to: #9925

At 11:42 AM 5/18/2004 +0200, Christian Schneider wrote:
>Sara Golemon wrote:
> > […]
>
>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

---

## #9956 — Andrey Hristov — 2004-05-20T07:28:10+00:00

URL: https://externals.io/message/9925#9956 · In reply to: #9950

Andi Gutmans wrote:
> At 11:42 AM 5/18/2004 +0200, Christian Schneider wrote:
> 
> > […]
> 
> 
> 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