json_encode ignores protected/private class members

I still don't see why json_encode ignores protected/private class
members. I mean, why we need this feature.

Because, in theory, it shouldn't even be able to see those members?

Stefan's right. Unless you are in the local scope or inheriting the
object you shouldn't be able to see those variables. And I have yet to
see

classs Name extends json_decode($jsonValues) { }

That's the point in having access modifiers. Unless I'm mistaking
there's no bug there.
well .. i think this is at least the common use case. then again, json
is an encoding format, and i expect that i can get the same object
state by decoding. so the expectation to also get non public
properties in the json encoded string is not totally crazy.

I'd have thought the common use case is that you only want the public
class members, unless you're inside the class. It could make sense to
have an additional "member visibility filter" flag of some kind,
defaulting to public visibility, but can be set to encode protected or
private members as well (for backwards compatibility). It would be nice
(I suppose) if it automatically encoded private/protected members as
well depending on context, but I'm not sure how complex it would be to
add, and how intuitive it would be.

I think that the solution given earlier is best though - explicitly
encoding the array returned by get_object_vars().

But when using json_encode I believe the developer wants to transfer
the complete object state, just like when using serialize.
Serialize does see private/protected class members, while json_encode not.
If you want to serialize an object, then use the appropriate function. I
think that json_encode() has the correct behaviour - encoding only the
publicly-visible structure of an object. They have fundamentally
different aims. If you want to expose data to an external source (e.g.
JavaScript) then surely it would make sense for it to be a public class
member? Why would you not want your PHP code to be able to access it?

Javascript does not have class-accessors so why not convert
protected/private to public javascript attributes.
That's true, although it does have convention that members beginning
with an underscore are generally understood to be treated as
private/protected.

Dave

On Thursday 09 October 2008 15:31:54 Lukas Kahwe Smith wrote:

well .. i think this is at least the common use case. then again, json
is an encoding format, and i expect that i can get the same object
state by decoding. so the expectation to also get non public
properties in the json encoded string is not totally crazy.

Well, you lose the information about the class anyway, so there is no way to
decode it to the previous state without implementing it yourself, and in
order to set private/protected attributes, you have to implement it as a
method ... and if you do that, it's natural that you also do a member
function that does the encoding, so the round-trip argument doesn't really
work.

however changing this at this point would be a huge security issue, so
if at all, it would need to be handled by an optional parameter that
defaults to false.

That would be unclean. If it's implemented in some way, json_encode should
look for the implementation of some interface (JSONEncodable or something)
providing encoding/decoding methods (similar to __sleep/__wakeup).

Regards,
Stefan

2008/10/9 Rodrigo Saboya rodrigo.saboya@bolsademulher.com:

Jarismar Chaves da Silva wrote:

I agree with you.
But when using json_encode I believe the developer wants to transfer the
complete object state, just like when using serialize.
Serialize does see private/protected class members, while json_encode not.
Javascript does not have class-accessors so why not convert
protected/private to public javascript attributes.

In theory only the public members are relevant to anyone except the object
itself. If you need information about private/protected members you are
either using the wrong visibility for your variables or using json for
something it's not supposed to do.

-- Rodrigo Saboya

--

A simply userland solution would be to use an abstract base class with
json_encode()/json_decode() as public final methods. All classes
needing to support json_encode/json_decode would simply need to extend
from this base class.

No need to add even more "magic" to the base stdClass.

Richard.

--

Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

Rodrigo Saboya wrote:

Jarismar Chaves da Silva wrote:

I agree with you.
But when using json_encode I believe the developer wants to transfer
the complete object state, just like when using serialize.
Serialize does see private/protected class members, while json_encode
not.
Javascript does not have class-accessors so why not convert
protected/private to public javascript attributes.

In theory only the public members are relevant to anyone except the
object itself. If you need information about private/protected members
you are either using the wrong visibility for your variables or using
json for something it's not supposed to do.

Yes, of course. But currently json_encode ignores the attributes even if
the call is from inside the class.
<?php
class Person {
protected $name;

public function __construct($sName) {
    $this->name = $sName;
}

public function toJSON() {
    return json_encode($this);
}

}

$person = new Person('jaris');
print $person->toJSON(); // ==> will print an empty object e.g. {}
?>

I don't know if I'm using json_encode for something it's not supposed to
do. I'm using it to serialize an object to send it to another
runtime-environment in response to an remote call, just like what I can
do with SOAP, REST or RMI. In this context I don't see much sense in
preventing protected/private data from being transfered.

Regards,
Jaris.

-- Rodrigo Saboya

--

Jarismar Chaves da Silva, M.Sc.

ADPLabs* Brazil**
*jarismar_silva@adplabs.com.br mailto:jarismar_silva@adplabs.com.br
http://www.adp.com