PHP 5 Bug Database summary - http://bugs.php.net/
Num Status Summary (1251 total -- which includes 766 feature requests)
===[*Configuration Issues]
46845 Assigned Test expected to fail, but pass, dont cause an error
46846 Open Regex
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (70 total -- which includes 31 feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
===
Hi!
Thanks, fixed.
Xuefer wrote:
opline2->op2.op_type == 0, which should be opline2->op2.op_type ==
IS_UNUSED. patch followed:
$ cvs diff zend_compile.c
Index: zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
Ok, so as promised I ran some of the options we have that came up last
week by Douglas Crockford.
1. Document the fact that if you want to strictly conform to the JSON
spec and be sure your json_encode output will work in various JSON
parsers, you have to pass it a PHP array or object.
2. R
On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf wrote:
> 1. Document the fact that if you want to strictly conform to the JSON
> spec and be sure your json_encode output will work in various JSON
> parsers, you have to pass it a PHP array or object.
Instead of json_encode(34) the suggestion
> -Original Message-
> From: mike [mailto:mike...@gmail.com]
> Sent: 15 December 2008 18:10
> To: Rasmus Lerdorf
> Cc: PHP Developers Mailing List
> Subject: Re: [PHP-DEV] json_encode()
>
> On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf
> wrote:
>
> > 1. Document the fact that if y
Jared Williams wrote:
> Don't think that's what he said... More like...
>
> assert(is_object($foo) || is_array($foo)); // ensure strictly conforming
> $json = json_encode($foo);
Which is, for all intents and purposes, the same thing. (Since you can't
pass json_encode(34) for strict JSON).
PHP ha
As is noted in an earlier mail, I would prefer 1 (simply document it in the
function description). In my opinion, if somebody then passes a basic type
to json_encode he is aware of what he is doing (hopefully).
For compatibility with current code and securely escaping strings for
javascript it is
On Mon, Dec 15, 2008 at 12:55 PM, Uwe Schindler wrote:
> As is noted in an earlier mail, I would prefer 1 (simply document it in the
> function description). In my opinion, if somebody then passes a basic type
> to json_encode he is aware of what he is doing (hopefully).
>
> For compatibility with
On Mon, Dec 15, 2008 at 10:02 PM, mike wrote:
> I'd like to see it "do the right thing" in PHP 6, and perhaps if
I think everybody agrees to that. The question at hand, is what the
right thing is.
I, for one, think that the only sane choices are 1 or 2. The third
option is way too magic, and wil
On Mon, Dec 15, 2008 at 1:10 PM, troels knak-nielsen wrote:
> I, for one, think that the only sane choices are 1 or 2. The third
> option is way too magic, and will end up confusing people.
In that case I would have to go for #2.
Personally I want to see PHP be as standards-compliant and compat
How about a strict mode added to the list of the current json_encode()
options?
That way current code will continue to work and anyone reading the docs
will know the default behaviour isn't strictly correct.
John.
John Carter
Development Manager
NAC Governance Server
Cisco
johnc...@cisco.com
+44
Edward Z. Yang wrote:
> Jared Williams wrote:
>> Don't think that's what he said... More like...
>>
>> assert(is_object($foo) || is_array($foo)); // ensure strictly conforming
>> $json = json_encode($foo);
>
> Which is, for all intents and purposes, the same thing. (Since you can't
> pass json_enc
On Mon, Dec 15, 2008 at 1:43 PM, John Carter -X (johncart - PolicyApp
Ltd at Cisco) wrote:
> How about a strict mode added to the list of the current json_encode()
> options?
>
> That way current code will continue to work and anyone reading the docs
> will know the default behaviour isn't strictl
Hi,
I believe part of the job should be the programmer's job too.
json_encode() is way too useful to pass things to javascript (the other
way around is not that easy, but I have a function called "JSparse"
which work nicely with .toSource() output, and an implementation
of .toSource() for MSIE, I
On Mon, Dec 15, 2008 at 8:58 PM, Mark Karpeles wrote:
> I believe part of the job should be the programmer's job too.
I'm a programmer. I expect json_* functions to encode and decode to
JSON specifications. Not PHP's original interpretation of it...
> Lazy mode is "not that good", as it's going
Hi,
JSON allows extensions. I can not understand why this is not an extension
that makes sense:
json_encode($var, $allowScalar = false);
In PHP outputting of JS literals is a common action, so all you'll achieve
by completely removing this option, is forcing people to go from this:
echo '
Hi Rasmus,
Am Montag, den 15.12.2008, 14:17 -0800 schrieb Rasmus Lerdorf:
[...]
> There has to be a way to do a basic type without any sort of error or
> warning. E_STRICT, even if turned off, is slow. It ends up calling
> php_verror to construct the entire error string before it checks and
> se
18 matches
Mail list logo
