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
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
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) "ää"
}
NULLUnderstand 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'sjson_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
Greetings,
It'd be beneficial if we waited to discuss this topic until after Sean proposes an RFC this weekend.
Regards,
Philip
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
david.zuelke@bitextender.com 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
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) "ää"
}
NULLUnderstand 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'sjson_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
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 ircmaxell@gmail.comwrote:
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
david.zuelke@bitextender.com 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 ownjson_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:
<?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) "ää"
}
NULLUnderstand 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'sjson_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 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 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
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