# JSON array/object syntax - Thread: https://externals.io/message/52877 - Original archive: https://news-web.php.net/php.internals/52877 - Started by dukeofgaming on 2011-06-04T01:17:36+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #52877 — dukeofgaming — 2011-06-04T01:17:36+00:00 URL: https://externals.io/message/52877#52877 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: That'll produce: > array(1) { > [0]=> > string(4) "ää" > } > `NULL` Understand what the problem is now? If someone does this in a latin1-encoded file: 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 --- ## #52883 — david.zuelke@bitextender.com — 2011-06-04T11:52:51+00:00 URL: https://externals.io/message/52877#52883 · In reply to: #52877 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 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 > 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: > > $chr = "\xC3\xA4"; // "ä" as UTF-8 > var_dump(json_decode('["' . $chr . '\u00e4"]')); > var_dump(json_decode('["' . utf8_decode($chr) . '\u00e4"]')); > ?> > > That'll produce: > > > […] > > Understand what the problem is now? > > If someone does this in a latin1-encoded file: > > > > 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 --- ## #52886 — Philip Olson — 2011-06-04T13:33:40+00:00 URL: https://externals.io/message/52877#52886 · In reply to: #52883 Greetings, It'd be beneficial if we waited to discuss this topic until after Sean proposes an RFC this weekend. Regards, Philip --- ## #52888 — Anthony Ferrara — 2011-06-04T16:32:09+00:00 URL: https://externals.io/message/52877#52888 · In reply to: #52883 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 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 > > > > > > […] --- ## #52972 — dukeofgaming — 2011-06-05T21:11:51+00:00 URL: https://externals.io/message/52877#52972 · In reply to: #52888 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: > > […] > 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 and ?> tags, so you couldn't just evaluate it as JavaScript (which would be > useless without assignment etc). > > […] > 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*. > > […] > to me > > […] > be > > […] > `json_decode()` > > […] > will > > […] > & > > […] > PHP. > > […] --- ## #52999 — Lester Caine — 2011-06-06T06:41:15+00:00 URL: https://externals.io/message/52877#52999 · In reply to: #52972 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 --- ## #53005 — dukeofgaming — 2011-06-06T09:09:36+00:00 URL: https://externals.io/message/52877#53005 · In reply to: #52999 > dukeofgaming wrote: > > > […] > > 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 --- ## #53006 — Lester Caine — 2011-06-06T09:53:52+00:00 URL: https://externals.io/message/52877#53006 · In reply to: #53005 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