Ok, so as promised I ran some of the options we have that came up last
week by Douglas Crockford.
-
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. -
Remove support for basic types entirely and throw an error if you
passjson_encode()something that is not an array or an object. -
Wrap basic types in an array [] by default and perhaps add an option
tojson_encode()to skip the wrapper.
He would prefer option 1.
-Rasmus
- 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 would be
json_encode(array(34)) ? Seems kind of like a lame thing to require.
IMHO the language should "do the right thing" as far as the consumer
(javascript/JSON parser) is concerned. However, Douglas is infinitely
more educated than I am here. This is just my $0.02 as a PHP user.
Remove support for basic types entirely and throw an error if you
passjson_encode()something that is not an array or an object.Wrap basic types in an array [] by default and perhaps add an option
tojson_encode()to skip the wrapper.
This sounds like what I had been talking about previously.
He would prefer option 1.
I'd be tempted to say #3. However that's probably a code change
everyone must make, I would expect that to be in a major release like
6.0.
2008/12/15 mike mike503@gmail.com:
- 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 would be
json_encode(array(34)) ? Seems kind of like a lame thing to require.
IMHO the language should "do the right thing" as far as the consumer
(javascript/JSON parser) is concerned. However, Douglas is infinitely
more educated than I am here. This is just my $0.02 as a PHP user.
I was one of those that read the PHP dox and not the RFC/standard
(http://bugs.php.net/bug.php?id=38680).
I would say that having PHP "correct" my mistake is wrong.
If I say...
json_encode(34);
I am saying that I expect the result to be ...
var i_SomeInt = 34;
And from there I would expect to be able to say ...
var i_SomeOtherInt = i_SomeInt + 10;
This is not going to work if PHP "corrects" my mistake.
I'd be perfectly happy for the standard to be enforced and an E_STRICT
warning to be raised.
If I want to shoot myself then I have to at least take the safety off
first - turning off E_STRICT that is.
Essentially, I don't like computers guessing my intent. If I don't
state it clearly enough then it may be that I don't know what I'm
doing.
GIMGO (Garbage In, Maybe Garbage Out) isn't a good way to go.
Richard.
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Richard Quadling wrote:
2008/12/15 mike mike503@gmail.com:
- 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 would be
json_encode(array(34)) ? Seems kind of like a lame thing to require.
IMHO the language should "do the right thing" as far as the consumer
(javascript/JSON parser) is concerned. However, Douglas is infinitely
more educated than I am here. This is just my $0.02 as a PHP user.I was one of those that read the PHP dox and not the RFC/standard
(http://bugs.php.net/bug.php?id=38680).I would say that having PHP "correct" my mistake is wrong.
If I say...
json_encode(34);
I am saying that I expect the result to be ...
var i_SomeInt = 34;
And from there I would expect to be able to say ...
var i_SomeOtherInt = i_SomeInt + 10;
This is not going to work if PHP "corrects" my mistake.
I'd be perfectly happy for the standard to be enforced and an
E_STRICT
warning to be raised.If I want to shoot myself then I have to at least take the safety off
first - turning offE_STRICTthat is.Essentially, I don't like computers guessing my intent. If I don't
state it clearly enough then it may be that I don't know what I'm
doing.GIMGO (Garbage In, Maybe Garbage Out) isn't a good way to go.
json_encode is NOT javascript encode, you're already shooting yourself
by miusing the function. The problem I'm talking about here is when
native browser functions are used to decode the JSON.
var json_resonse = <?php echo json_encode(42); ?>;
var myfoo = JSON.parse(json_resonse);
The result here is an exception thrown by the browser, if you try and
use JSON to speak to perl, python or ruby you get a similar error. The
same applies for the various frameworks out there too.
For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
parameter to the options flag. So you can use
json_encode($var, JSON_STRICT_ENCODE);
Scott
For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
parameter to the options flag. So you can usejson_encode($var, JSON_STRICT_ENCODE);
I'm really not a fan of named constants to change the semantics of a
function like that. Not to mention that it's a pita to type out, so
nobody would bother. It also doesn't address the crux of the matter -
That the name json_encode is slightly misleading, in that it may or
may not emit json.
Would it be a problem to introduce a second function (js_encode?)
instead? It could work as json_encode does today, and json_encode
could then be changed to raise a warning on illegal input. I realise
that this means breaking existing scripts, but it's a trivial change,
and if it's announced in advance, people should have time to make that
sed -r '/json_encode/js_encode/g' to their code base.
--
troels
troels knak-nielsen wrote:
For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
parameter to the options flag. So you can usejson_encode($var, JSON_STRICT_ENCODE);
I'm really not a fan of named constants to change the semantics of a
function like that. Not to mention that it's a pita to type out, so
nobody would bother. It also doesn't address the crux of the matter -
That the name json_encode is slightly misleading, in that it may or
may not emit json.Would it be a problem to introduce a second function (js_encode?)
instead? It could work as json_encode does today, and json_encode
could then be changed to raise a warning on illegal input. I realise
that this means breaking existing scripts, but it's a trivial change,
and if it's announced in advance, people should have time to make that
sed -r '/json_encode/js_encode/g' to their code base.
We already have PHP_JSON_HEX_QUOT, PHP_JSON_HEX_TAG, PHP_JSON_HEX_AMP
and PHP_JSON_HEX_APOS as options for json_encode, this would just be
adding another bitmask.
In the future if need be we can make it the default value so it raises a
warning. I have no interest in doing a js_encode functions as it opens
us up to implementing a lot more functionality.
The appealing this about json is that its a subset of JavaScript.
Scott
For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
parameter to the options flag. So you can usejson_encode($var, JSON_STRICT_ENCODE);
I'm really not a fan of named constants to change the semantics of a
function like that. Not to mention that it's a pita to type out, so
nobody would bother. It also doesn't address the crux of the matter -
That the name json_encode is slightly misleading, in that it may or
may not emit json.Would it be a problem to introduce a second function (js_encode?)
instead? It could work as json_encode does today, and json_encode
could then be changed to raise a warning on illegal input. I realise
that this means breaking existing scripts, but it's a trivial change,
and if it's announced in advance, people should have time to make that
sed -r '/json_encode/js_encode/g' to their code base.
sounds like a proper way to me
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
parameter to the options flag. So you can usejson_encode($var, JSON_STRICT_ENCODE);
I'm really not a fan of named constants to change the semantics of a
function like that. Not to mention that it's a pita to type out, so
nobody would bother. It also doesn't address the crux of the matter -
That the name json_encode is slightly misleading, in that it may or
may not emit json.Would it be a problem to introduce a second function (js_encode?)
instead? It could work as json_encode does today, and json_encode
could then be changed to raise a warning on illegal input. I realise
that this means breaking existing scripts, but it's a trivial change,
and if it's announced in advance, people should have time to make that
sed -r '/json_encode/js_encode/g' to their code base.sounds like a proper way to me
Me too, but I rather name the function js_escape instead of js_encode.
2008/12/16 Scott MacVicar scott@macvicar.net:
Richard Quadling wrote:
2008/12/15 mike mike503@gmail.com:
- 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 would be
json_encode(array(34)) ? Seems kind of like a lame thing to require.
IMHO the language should "do the right thing" as far as the consumer
(javascript/JSON parser) is concerned. However, Douglas is infinitely
more educated than I am here. This is just my $0.02 as a PHP user.I was one of those that read the PHP dox and not the RFC/standard
(http://bugs.php.net/bug.php?id=38680).I would say that having PHP "correct" my mistake is wrong.
If I say...
json_encode(34);
I am saying that I expect the result to be ...
var i_SomeInt = 34;
And from there I would expect to be able to say ...
var i_SomeOtherInt = i_SomeInt + 10;
This is not going to work if PHP "corrects" my mistake.
I'd be perfectly happy for the standard to be enforced and an
E_STRICT
warning to be raised.If I want to shoot myself then I have to at least take the safety off
first - turning offE_STRICTthat is.Essentially, I don't like computers guessing my intent. If I don't
state it clearly enough then it may be that I don't know what I'm
doing.GIMGO (Garbage In, Maybe Garbage Out) isn't a good way to go.
json_encode is NOT javascript encode, you're already shooting yourself
by miusing the function. The problem I'm talking about here is when
native browser functions are used to decode the JSON.var json_resonse = <?php echo json_encode(42); ?>;
var myfoo = JSON.parse(json_resonse);The result here is an exception thrown by the browser, if you try and
use JSON to speak to perl, python or ruby you get a similar error. The
same applies for the various frameworks out there too.
When I say "expect", it was because the PHP documentation said I could.
I like the option to either have strict encoding as standard or as an
option I can activate myself. Either way, I want to be told if I've
done it wrong.
For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
parameter to the options flag. So you can usejson_encode($var, JSON_STRICT_ENCODE);
+1
Would it be at all possible to have an ini setting json.strict_encode = On
So, my code doesn't change, but I can activate it globally.
Essentially I don't want to shoot myself. I don't want to take the
safety off.
Scott
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
On Tue, Dec 16, 2008 at 3:06 PM, Richard Quadling
rquadling@googlemail.com wrote:
Would it be at all possible to have an ini setting json.strict_encode = On
So, my code doesn't change, but I can activate it globally.
Essentially I don't want to shoot myself. I don't want to take the
safety off.
I think we have lots of prior examples of why it's a bad idea to
change language semantics with a global setting.
--
troels
Settings which change behaviour like that aren't really all that fun
for third party/portable applications developers, e.g. forum software
and the likes. magic_quotes_gpc and others are good examples of this.
Going back to Rasmus' mail based on his discussion with Douglas, I
think that option #1 (documenting the way it works, and documenting
how to do things "properly") sounds perfectly fine.
On Tue, Dec 16, 2008 at 2:06 PM, Richard Quadling
rquadling@googlemail.com wrote:
2008/12/16 Scott MacVicar scott@macvicar.net:
Richard Quadling wrote:
2008/12/15 mike mike503@gmail.com:
- 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 would be
json_encode(array(34)) ? Seems kind of like a lame thing to require.
IMHO the language should "do the right thing" as far as the consumer
(javascript/JSON parser) is concerned. However, Douglas is infinitely
more educated than I am here. This is just my $0.02 as a PHP user.I was one of those that read the PHP dox and not the RFC/standard
(http://bugs.php.net/bug.php?id=38680).I would say that having PHP "correct" my mistake is wrong.
If I say...
json_encode(34);
I am saying that I expect the result to be ...
var i_SomeInt = 34;
And from there I would expect to be able to say ...
var i_SomeOtherInt = i_SomeInt + 10;
This is not going to work if PHP "corrects" my mistake.
I'd be perfectly happy for the standard to be enforced and an
E_STRICT
warning to be raised.If I want to shoot myself then I have to at least take the safety off
first - turning offE_STRICTthat is.Essentially, I don't like computers guessing my intent. If I don't
state it clearly enough then it may be that I don't know what I'm
doing.GIMGO (Garbage In, Maybe Garbage Out) isn't a good way to go.
json_encode is NOT javascript encode, you're already shooting yourself
by miusing the function. The problem I'm talking about here is when
native browser functions are used to decode the JSON.var json_resonse = <?php echo json_encode(42); ?>;
var myfoo = JSON.parse(json_resonse);The result here is an exception thrown by the browser, if you try and
use JSON to speak to perl, python or ruby you get a similar error. The
same applies for the various frameworks out there too.When I say "expect", it was because the PHP documentation said I could.
I like the option to either have strict encoding as standard or as an
option I can activate myself. Either way, I want to be told if I've
done it wrong.For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
parameter to the options flag. So you can usejson_encode($var, JSON_STRICT_ENCODE);
+1
Would it be at all possible to have an ini setting json.strict_encode = On
So, my code doesn't change, but I can activate it globally.
Essentially I don't want to shoot myself. I don't want to take the
safety off.Scott
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
2008/12/16 Robin Burchell viroteck@viroteck.net:
Settings which change behaviour like that aren't really all that fun
for third party/portable applications developers, e.g. forum software
and the likes. magic_quotes_gpc and others are good examples of this.Going back to Rasmus' mail based on his discussion with Douglas, I
think that option #1 (documenting the way it works, and documenting
how to do things "properly") sounds perfectly fine.
Ok, I see. Add the optional param to the function and have a one-off
hit to the userland codebase to fix the problem.
So is this going to be 5.3 or 6.0?
Would you expect json_decode() to have the param as well.
Considering json_encode() COULD encode non JSON compliant data, should
json_decode() also decode non JSON compliant data?
Richard.
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
On Wed, Dec 17, 2008 at 1:05 PM, Richard Quadling
rquadling@googlemail.com wrote:
Considering
json_encode()COULD encode non JSON compliant data, should
json_decode()also decode non JSON compliant data?
it should decode as much as it can without any warnings (as long, as
there's no ambiguity)
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
Richard Quadling wrote:
2008/12/16 Robin Burchell viroteck@viroteck.net:
Settings which change behaviour like that aren't really all that fun
for third party/portable applications developers, e.g. forum software
and the likes. magic_quotes_gpc and others are good examples of this.Going back to Rasmus' mail based on his discussion with Douglas, I
think that option #1 (documenting the way it works, and documenting
how to do things "properly") sounds perfectly fine.Ok, I see. Add the optional param to the function and have a one-off
hit to the userland codebase to fix the problem.So is this going to be 5.3 or 6.0?
Would you expect
json_decode()to have the param as well.Considering
json_encode()COULD encode non JSON compliant data, should
json_decode()also decode non JSON compliant data?
I assume you always check the return value of json_decode() before you
do anything with it in case of error etc. So there is no need to add a
flag in my opinion to this.
I have one patch that updates the parser to be more readable and add an
optional depth limit to json_decode() and another patch to add flags for
this.
Time permitting I'll do it today.
Scott
The proposed solution (basic types flag) is probably the lesser evil,
but I still feel were are taking things to far and current operation
is correct.
Richard Quadling wrote:
2008/12/15 mike mike503@gmail.com:
On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf
rasmus@lerdorf.com wrote:
- 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 would be
json_encode(array(34)) ? Seems kind of like a lame thing to require.
IMHO the language should "do the right thing" as far as the consumer
(javascript/JSON parser) is concerned. However, Douglas is
infinitely
more educated than I am here. This is just my $0.02 as a PHP user.I was one of those that read the PHP dox and not the RFC/standard
(http://bugs.php.net/bug.php?id=38680).I would say that having PHP "correct" my mistake is wrong.
If I say...
json_encode(34);
I am saying that I expect the result to be ...
var i_SomeInt = 34;
And from there I would expect to be able to say ...
var i_SomeOtherInt = i_SomeInt + 10;
This is not going to work if PHP "corrects" my mistake.
I'd be perfectly happy for the standard to be enforced and an
E_STRICT
warning to be raised.If I want to shoot myself then I have to at least take the safety off
first - turning offE_STRICTthat is.Essentially, I don't like computers guessing my intent. If I don't
state it clearly enough then it may be that I don't know what I'm
doing.GIMGO (Garbage In, Maybe Garbage Out) isn't a good way to go.
json_encode is NOT javascript encode, you're already shooting yourself
by miusing the function. The problem I'm talking about here is when
native browser functions are used to decode the JSON.var json_resonse = <?php echo json_encode(42); ?>;
var myfoo = JSON.parse(json_resonse);The result here is an exception thrown by the browser, if you try and
use JSON to speak to perl, python or ruby you get a similar error. The
same applies for the various frameworks out there too.For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
parameter to the options flag. So you can usejson_encode($var, JSON_STRICT_ENCODE);
Scott
--
Ilia Alshanetsky
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 the best.
Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Monday, December 15, 2008 6:50 PM
To: PHP Developers Mailing List
Subject: [PHP-DEV]json_encode()Ok, so as promised I ran some of the options we have that came up last
week by Douglas Crockford.
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.Remove support for basic types entirely and throw an error if you
passjson_encode()something that is not an array or an object.Wrap basic types in an array [] by default and perhaps add an option
tojson_encode()to skip the wrapper.He would prefer option 1.
-Rasmus
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 the best.
PHP 6 will require some recoding for various things.
I'd like to see it "do the right thing" in PHP 6, and perhaps if
people are using json_encode for escaping, make another function that
is there purely for escaping javascript, not serializing/unserializing
it for direct exchange with JSON consumption in javascript. After all,
this is json_encode, not javascript_escape ...
I was unaware that json_encode() [improperly] encoded
non-arrays/objects, as I expected those details to be worked out in
the implementation. While it does produce legitimate javascript it
does not produce legitimate JSON, which is the purpose of these
functions, no?
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 will end up confusing people.
--
troels
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 compatible
with everything out there. I don't want non-standard behaviors in PHP
to be the things that make it a harder sell when I am pushing it in
everything I do. This is a language interoperability issue (more or
less) and rather than being lazy and persisting the same behavior, I
am trying to push very hard to make it work as JSON consumers expect.
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
johncart@cisco.com
+44 161 249 5825
On Mon, Dec 15, 2008 at 1:43 PM, John Carter -X (johncart - PolicyApp
Ltd at Cisco) johncart@cisco.com 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 strictly correct.
I'd rather have a "lazy mode" option, so by default it is spitting out
correct JSON (according to specs)
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 was doing json with that even before json
existed).
I'm in favour of #1.
Lazy mode is "not that good", as it's going to break things anyway by
silently doing magic stuff the final developer didn't expect because it
didn't happen in previous versions.
Mark
Le lundi 15 décembre 2008 à 14:34 -0800, mike a écrit :
On Mon, Dec 15, 2008 at 1:43 PM, John Carter -X (johncart - PolicyApp
Ltd at Cisco) johncart@cisco.com 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 strictly correct.I'd rather have a "lazy mode" option, so by default it is spitting out
correct JSON (according to specs)
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 to break things anyway by
silently doing magic stuff the final developer didn't expect because it
didn't happen in previous versions.
Okay, well PHP 6's behavior is going to change certain things already.
Hence why I would recommend the change to be in a major version (6.x)
But in the meantime, we're going to be stuck using a construct that
works but does not work to actual specification and we're just going
to "stick with it" because it will be a change?
PHP does "magic" already on a variety of things behind the scenes,
there should be no reason why this is any different.
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 'var foo = '.json_encode("hello world");
...to this:
echo 'var foo = '.substr(json_encode(array("hi world")), 1, -1);
A flag that defaults to false would be just as explicit and educational, and
more efficient, than forcing hacks on us like the above one.
Regards,
Stan Vassilev
Ok, so as promised I ran some of the options we have that came up last
week by Douglas Crockford.
- 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.
+1
Cheers,
Pierre
- 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.
+1
Regards,
Stan Vassilev
Hi.
Ok, so as promised I ran some of the options we have that came up last
week by Douglas Crockford.
- 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.
+1
Karsten Dambekalns