Hi,
So I guess the conclusion is:
Create a feature request ticket, take the information from this thread
and put it into the ticket .. and ideally write a patch yourself or
motivate someone else ..
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
Hi Jaris:
> 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 i
2008/10/9 Rodrigo Saboya <[EMAIL PROTECTED]>:
> 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
2008/10/10 Jarismar Chaves da Silva <[EMAIL PROTECTED]>:
>
>
> 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
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 n
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 s
Yes, it like it too. Just like an OOP should be.
Dave Ingram wrote:
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, j
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/priv
Ron Rademaker wrote:
> Stefan Walk wrote:
>> 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).
> Looking at our current JSO
>> 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 inte
On Thursday 09 October 2008 15:13:43 Jarismar Chaves da Silva wrote:
> Ok, nice solution, but 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?
Regards,
Stefan
--
PH
Stefan Walk wrote:
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).
Looking at our current JSON implementations, such an interfa
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
On 09.10.2008, at 15:45, Dave Ingram wrote:
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 t
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 a
On 09.10.2008, at 15:26, David Coallier wrote:
Ok, nice solution, but 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 loca
>> Ok, nice solution, but 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 should
Ok, nice solution, but I still don't see why json_encode ignores
protected/private class members. I mean, why we need this feature.
Vesselin Kenashkov wrote:
Until this gets fixed instead of declaring the properties public you
can use a encode method like this:
p1;
return json_encode(get_
Until this gets fixed instead of declaring the properties public you can use
a encode method like this:
p1;
return json_encode(get_object_vars($this));//this will encode the
protected var
}
}
$o = new c1;
print $o->enc();
?>
On Thu, Oct 9, 2008 at 3:54 PM, Jarismar Chaves da Silva <
[EMAIL
19 matches
Mail list logo
