Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40892
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain dmi.me.uk designates 213.171.205.116 as permitted sender)
Message-ID: <48EE0AF9.8020602@dmi.me.uk>
Date: Thu, 09 Oct 2008 14:45:29 +0100
User-Agent: Thunderbird 2.0.0.17 (X11/20080914)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: David Coallier <davidc@php.net>, Stefan Walk <et@php.net>, 
 internals@lists.php.net
References: <48EDFEED.8080605@adplabs.com.br> <261daaa10810090607h1876200ex1efa43a40cfb24c2@mail.gmail.com> <48EE0387.3040802@adplabs.com.br> <200810091517.37703.et@php.net> <b5f7bf6c0810090626r247d4c66o14cfa836f5860054@mail.gmail.com> <DA86E2D1-34A1-49B9-9E05-7AD9AD6A9DC0@pooteeweet.org>
In-Reply-To: <DA86E2D1-34A1-49B9-9E05-7AD9AD6A9DC0@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] json_encode ignores protected/private class members
From: dave@dmi.me.uk (Dave Ingram)


>>>> 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