FAQ
Hi,

After reading all the debate in the other thread it is still not clear to me
what the real advantages are of adopting JSON syntax for native PHP
types. Doing json_encode to an object and expect the code and output to be
the same seems useless to me, and reading David Zülke's example it seems
more like a pure-unicode issue to me:

----

It is different from writing json_decode('ä\u0123'), because json_decode()
in PHP only accepts UTF-8 encoded input;

Give it a shot:

<?php
$chr = "\xC3\xA4"; // "ä" as UTF-8
var_dump(json_decode('["' . $chr . '\u00e4"]'));
var_dump(json_decode('["' . utf8_decode($chr) . '\u00e4"]'));
?>

That'll produce:
array(1) {
[0]=>
string(4) "ää"
}
NULL
Understand what the problem is now?

If someone does this in a latin1-encoded file:

<?php $fancyNewArray = {"yay": "ä"}; ?>

Then that is valid as a PHP array (as it's a latin1 "ä", so \xE4), but
cannot be consumed by PHP's json_decode(). And that would be terribly
inconsistent behavior.

-----

It looks more like you want to do json_decode to PHP code hoping that will
somehow fix json_decode... instead of fixing json_decode.

Could someone advocating this please explain with use-cases and concrete &
punctualized examples the advantages of having such JSON approach to PHP.

Regards,

David Vega

Search Discussions

  • David Zülke at Jun 4, 2011 at 11:53 am
    To clarify: I don't understand what the advantage would be, either. It seems that those demanding it somehow confuse or blur the lines between the declaration of data in the language and its representation in a serialization format. A few people in the thread demanded that it be a syntax that could also be consumed by all the JSON parsers out there, and I have no idea how that would be useful at all, since the construct per se isn't useful at all as PHP code and at least needs to be wrapped in <?php and ?> tags, so you couldn't just evaluate it as JavaScript (which would be useless without assignment etc).

    I ignored that aspect as others covered it already (e.g. Pierre asking what the point was of this at all) and focused on the encoding issue that *would* occur if someone, somehow managed to find a useful way of taking advantage of such a notation (e.g. where it would be interchangeable with JS code or be evaluated as JSON by other JSON parsers) - namely the problem that you could produce *PHP code*, that, with some mingling and stripping, *PHP's own json_decode() could not process*.

    Perhaps I should have made that more clear, sorry.

    David

    On 04.06.2011, at 03:17, dukeofgaming wrote:

    Hi,

    After reading all the debate in the other thread it is still not clear to me
    what the real advantages are of adopting JSON syntax for native PHP
    types. Doing json_encode to an object and expect the code and output to be
    the same seems useless to me, and reading David Zülke's example it seems
    more like a pure-unicode issue to me:

    ----

    It is different from writing json_decode('ä\u0123'), because json_decode()
    in PHP only accepts UTF-8 encoded input;

    Give it a shot:

    <?php
    $chr = "\xC3\xA4"; // "ä" as UTF-8
    var_dump(json_decode('["' . $chr . '\u00e4"]'));
    var_dump(json_decode('["' . utf8_decode($chr) . '\u00e4"]'));
    ?>

    That'll produce:
    array(1) {
    [0]=>
    string(4) "ää"
    }
    NULL
    Understand what the problem is now?

    If someone does this in a latin1-encoded file:

    <?php $fancyNewArray = {"yay": "ä"}; ?>

    Then that is valid as a PHP array (as it's a latin1 "ä", so \xE4), but
    cannot be consumed by PHP's json_decode(). And that would be terribly
    inconsistent behavior.

    -----

    It looks more like you want to do json_decode to PHP code hoping that will
    somehow fix json_decode... instead of fixing json_decode.

    Could someone advocating this please explain with use-cases and concrete &
    punctualized examples the advantages of having such JSON approach to PHP.

    Regards,

    David Vega
  • Philip Olson at Jun 4, 2011 at 1:33 pm
    Greetings,

    It'd be beneficial if we waited to discuss this topic until after Sean proposes an RFC this weekend.

    Regards,
    Philip
  • Anthony Ferrara at Jun 4, 2011 at 4:33 pm
    One advantage would be familiarity. New developers only need to worry
    about 1 syntax, rather than a new one for each language. I'm not
    saying if it's worth it or not, but there is something to be said for
    consistency and using already established patterns and syntaxes if it
    makes sense (aka: there is no compelling reason not to). So far I
    haven't seen any compelling reason not to do it. Not saying they
    aren't there, nor that there aren't justifiable reasons in the
    threads. Just that I don't find any of the reasons against it
    compelling enough to say it doesn't make sense to use a json-style
    syntax.

    Just my 0.02...

    On Sat, Jun 4, 2011 at 7:52 AM, David Zülke
    wrote:
    To clarify: I don't understand what the advantage would be, either. It seems that those demanding it somehow confuse or blur the lines between the declaration of data in the language and its representation in a serialization format. A few people in the thread demanded that it be a syntax that could also be consumed by all the JSON parsers out there, and I have no idea how that would be useful at all, since the construct per se isn't useful at all as PHP code and at least needs to be wrapped in <?php and ?> tags, so you couldn't just evaluate it as JavaScript (which would be useless without assignment etc).

    I ignored that aspect as others covered it already (e.g. Pierre asking what the point was of this at all) and focused on the encoding issue that *would* occur if someone, somehow managed to find a useful way of taking advantage of such a notation (e.g. where it would be interchangeable with JS code or be evaluated as JSON by other JSON parsers) - namely the problem that you could produce *PHP code*, that, with some mingling and stripping, *PHP's own json_decode() could not process*.

    Perhaps I should have made that more clear, sorry.

    David

    On 04.06.2011, at 03:17, dukeofgaming wrote:

    Hi,

    After reading all the debate in the other thread it is still not clear to me
    what the real advantages are of adopting JSON syntax for native PHP
    types. Doing json_encode to an object and expect the code and output to be
    the same seems useless to me, and reading David Zülke's example it seems
    more like a pure-unicode issue to me:

    ----

    It is different from writing json_decode('ä\u0123'), because json_decode()
    in PHP only accepts UTF-8 encoded input;

    Give it a shot:

    <?php
    $chr = "\xC3\xA4"; // "ä" as UTF-8
    var_dump(json_decode('["' . $chr . '\u00e4"]'));
    var_dump(json_decode('["' . utf8_decode($chr) . '\u00e4"]'));
    ?>

    That'll produce:
    array(1) {
    [0]=>
    string(4) "ää"
    }
    NULL
    Understand what the problem is now?

    If someone does this in a latin1-encoded file:

    <?php $fancyNewArray = {"yay": "ä"}; ?>

    Then that is valid as a PHP array (as it's a latin1 "ä", so \xE4), but
    cannot be consumed by PHP's json_decode(). And that would be terribly
    inconsistent behavior.

    -----

    It looks more like you want to do json_decode to PHP code hoping that will
    somehow fix json_decode... instead of fixing json_decode.

    Could someone advocating this please explain with use-cases and concrete &
    punctualized examples the advantages of having such JSON approach to PHP.

    Regards,

    David Vega
  • Dukeofgaming at Jun 5, 2011 at 9:12 pm
    Ok, I found that Ruby added support for a new JSONy syntax a little while
    ago, this is interesting:

    http://www.strictlyuntyped.com/2010/12/new-ruby-19-hash-syntax.html
    http://webonrails.com/2009/02/06/ruby-191-hash/

    But it doesn't have anything to do with JSON interoperability.
    On Sat, Jun 4, 2011 at 11:32 AM, Anthony Ferrara wrote:

    One advantage would be familiarity. New developers only need to worry
    about 1 syntax, rather than a new one for each language. I'm not
    saying if it's worth it or not, but there is something to be said for
    consistency and using already established patterns and syntaxes if it
    makes sense (aka: there is no compelling reason not to). So far I
    haven't seen any compelling reason not to do it. Not saying they
    aren't there, nor that there aren't justifiable reasons in the
    threads. Just that I don't find any of the reasons against it
    compelling enough to say it doesn't make sense to use a json-style
    syntax.

    Just my 0.02...

    On Sat, Jun 4, 2011 at 7:52 AM, David Zülke
    wrote:
    To clarify: I don't understand what the advantage would be, either. It
    seems that those demanding it somehow confuse or blur the lines between the
    declaration of data in the language and its representation in a
    serialization format. A few people in the thread demanded that it be a
    syntax that could also be consumed by all the JSON parsers out there, and I
    have no idea how that would be useful at all, since the construct per se
    isn't useful at all as PHP code and at least needs to be wrapped in <?php
    and ?> tags, so you couldn't just evaluate it as JavaScript (which would be
    useless without assignment etc).
    I ignored that aspect as others covered it already (e.g. Pierre asking
    what the point was of this at all) and focused on the encoding issue that
    *would* occur if someone, somehow managed to find a useful way of taking
    advantage of such a notation (e.g. where it would be interchangeable with JS
    code or be evaluated as JSON by other JSON parsers) - namely the problem
    that you could produce *PHP code*, that, with some mingling and stripping,
    *PHP's own json_decode() could not process*.
    Perhaps I should have made that more clear, sorry.

    David

    On 04.06.2011, at 03:17, dukeofgaming wrote:

    Hi,

    After reading all the debate in the other thread it is still not clear
    to me
    what the real advantages are of adopting JSON syntax for native PHP
    types. Doing json_encode to an object and expect the code and output to
    be
    the same seems useless to me, and reading David Zülke's example it seems
    more like a pure-unicode issue to me:

    ----

    It is different from writing json_decode('ä\u0123'), because
    json_decode()
    in PHP only accepts UTF-8 encoded input;

    Give it a shot:

    <?php
    $chr = "\xC3\xA4"; // "ä" as UTF-8
    var_dump(json_decode('["' . $chr . '\u00e4"]'));
    var_dump(json_decode('["' . utf8_decode($chr) . '\u00e4"]'));
    ?>

    That'll produce:
    array(1) {
    [0]=>
    string(4) "ää"
    }
    NULL
    Understand what the problem is now?

    If someone does this in a latin1-encoded file:

    <?php $fancyNewArray = {"yay": "ä"}; ?>

    Then that is valid as a PHP array (as it's a latin1 "ä", so \xE4), but
    cannot be consumed by PHP's json_decode(). And that would be terribly
    inconsistent behavior.

    -----

    It looks more like you want to do json_decode to PHP code hoping that
    will
    somehow fix json_decode... instead of fixing json_decode.

    Could someone advocating this please explain with use-cases and concrete
    &
    punctualized examples the advantages of having such JSON approach to
    PHP.
    Regards,

    David Vega
  • Lester Caine at Jun 6, 2011 at 6:41 am

    dukeofgaming wrote:
    Ok, I found that Ruby added support for a new JSONy syntax a little while
    ago, this is interesting:

    http://webonrails.com/2009/02/06/ruby-191-hash/

    But it doesn't have anything to do with JSON interoperability.
    I'd rather no have to learn ruby either, but a scan of that document would seem
    to indicate that THEIR problem that was fixed was one of the way things were
    incorrectly ordered after using 'associate'. I'm seeing '=>' as the 'associate'
    which makes perfect sense there, when they use ':' to indicate variables.

    Add the warnings that "This only works if the key is a symbol." and one sees the
    sort of confusing mess that hopefully we are trying to avoid in PHP.

    --
    Lester Caine - G8HFL
    -----------------------------
    Contact - http://lsces.co.uk/wiki/?page=contact
    L.S.Caine Electronic Services - http://lsces.co.uk
    EnquirySolve - http://enquirysolve.com/
    Model Engineers Digital Workshop - http://medw.co.uk//
    Firebird - http://www.firebirdsql.org/index.php
  • Dukeofgaming at Jun 6, 2011 at 9:10 am

    On Mon, Jun 6, 2011 at 1:41 AM, Lester Caine wrote:

    dukeofgaming wrote:
    Ok, I found that Ruby added support for a new JSONy syntax a little while
    ago, this is interesting:

    http://webonrails.com/2009/02/06/ruby-191-hash/

    But it doesn't have anything to do with JSON interoperability.
    I'd rather no have to learn ruby either, but a scan of that document would
    seem to indicate that THEIR problem that was fixed was one of the way things
    were incorrectly ordered after using 'associate'. I'm seeing '=>' as the
    'associate' which makes perfect sense there, when they use ':' to indicate
    variables.

    Add the warnings that "This only works if the key is a symbol." and one
    sees the sort of confusing mess that hopefully we are trying to avoid in
    PHP.
    I'm just trying to point out that the ubiquity of the general syntax looks
    like a good thing.

    Also, that JSON has nothing to do with the syntax because the syntax makes
    sense by itself since it has proved to be expressive enough to become
    respected in various communities. But the JSONy argument should be dropped
    asap if this proposal is to be taken seriously.

    I'm not saying PHP should copy Ruby's rules, please don't imply that.

    Regards,

    David
  • Lester Caine at Jun 6, 2011 at 9:55 am

    dukeofgaming wrote:
    I'm not saying PHP should copy Ruby's rules, please don't imply that.
    Sorry - all I was trying to point out that even Ruby seems to be as inconsistent
    as everywhere else in this area.

    Personally I don't like the idea of add 'yet another' way of doing things.
    => is a consistent way of working in PHP. anything JSON related need to be
    checked against the more restricted JSON rules there, so 'hiding' that inside
    the more general parsing just seems wrong? There are enough areas where you can
    do the same thing several ways all of which are write, but which make other
    users reading of the code more difficult.

    --
    Lester Caine - G8HFL
    -----------------------------
    Contact - http://lsces.co.uk/wiki/?page=contact
    L.S.Caine Electronic Services - http://lsces.co.uk
    EnquirySolve - http://enquirysolve.com/
    Model Engineers Digital Workshop - http://medw.co.uk//
    Firebird - http://www.firebirdsql.org/index.php

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJun 4, '11 at 1:18a
activeJun 6, '11 at 9:55a
posts8
users5
websitephp.net

People

Translate

site design / logo © 2022 Grokbase