2008/10/10 Lukas Kahwe Smith <[EMAIL PROTECTED]>:
> Hi All,
>
> There was an offline exchange, which generated a lot of good ideas, but that
> failed to find agreement for one final proposal among the participants. I
> had hoped that the results would have been mailed to this list yesterday.
> Sinc
Hi All,
There was an offline exchange, which generated a lot of good ideas,
but that failed to find agreement for one final proposal among the
participants. I had hoped that the results would have been mailed to
this list yesterday. Since I am going on yet another frisbee trip in
about an
Sorry for the duplicate, Ilia, forgot to copy to list.
Ilia Alshanetsky wrote:
> The first release candidate of 5.2.7 was just released for testing and
> can be downloaded here:
You still haven't fixed the LC_CTYPE issue, have you?
http://marc.info/?l=php-internals&m=121813076018214&w=2
You sho
Cristian Rodríguez wrote:
> 田中 裕一 escribió:
>> Hi all,
>>
>> Could anyone tell me the license of the binaries and source code placed here?
>> http://pecl2.php.net/downloads/php-windows-builds/
>>
>> I am developing a commercial package software using PHP and I will build
>> libraries and PHP my own
田中 裕一 escribió:
> Hi all,
>
> Could anyone tell me the license of the binaries and source code placed here?
> http://pecl2.php.net/downloads/php-windows-builds/
>
> I am developing a commercial package software using PHP and I will build
> libraries and PHP my own.
> Is it ok to use Visual Studio
Hi all,
Could anyone tell me the license of the binaries and source code placed here?
http://pecl2.php.net/downloads/php-windows-builds/
I am developing a commercial package software using PHP and I will build
libraries and PHP my own.
Is it ok to use Visual Studio project files in these zip file
The first release candidate of 5.2.7 was just released for testing and
can be downloaded here:
http://downloads.php.net/ilia/php-5.2.7RC1.tar.bz2 (md5sum:
be7544212fe4a3ede775a3793ecd3967)
The Windows binaries should become available shortly as well, for now
you can grab the win32 snapsho
Hi Ilia,
What's about a mail to announce a deadline for the RC before tagging
it? It would be nice if you announce it before in a the future, thanks
:)
Cheers,
--
Pierre
On Fri, Oct 10, 2008 at 1:16 AM, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> iliaa Thu Oct 9 23:16:41 2008 UTC
>
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
Hi internals,
Does anyone knows why json_encode ignores protected/public class members ?
I've searching about it on documentation an mailing lists but found
nothing but workarounds.
Until now I'm forced to change my classes to use public members when I
need to send a PHP object on e.g. AJAX
Hi Ilia
2008/10/8 Ilia Cheishvili <[EMAIL PROTECTED]>:
> What did we decide to do about this patch? I noticed that it never got any
> feedback about the actual patch. Could someone take a look?
> Thanks!
This bug was fixed 5 days ago by Arnaud, which abit different patch:
http://news.php.net/ph
24 matches
Mail list logo
