On 05/31/2011 02:25 PM, Stas Malyshev wrote:
> Hi!
>
>> Stas, I didn't understand your point about eval() and security. What did
>> you mean?
>
> I meant if PHP has JSON syntax as native, e.g. you can say something like:
>
> $a = {"a":"b"};
>
> Then the temptation would be to write something like:
>
> // $json_string is {"a":"b"}
> $a = eval($json_string);
We could perhaps catch that case. I'm not sure that is a reason to
reject the idea. People who use eval() on user-supplied data are already
lost causes and trying to design for that case is tricky.
> Also, with full JSON support it is not entirely clear to me what {"a":
> "b"} would mean - is it an array or an object? In JS, it's definitely an
> object, but in PHP objects are almost never used to store pure state
> without behavior, because we have hashtable arrays, while JS only has
> vector arrays. So here we have some unclear point (which does not happen
> with [] syntax, since with [] it's obvious we're talking about arrays,
> just as in many other languages).
Right, this is a trickier issue. In order to handle both associative
arrays and objects the PHP notation would need to be along the lines of:
[ 1,2,3 ] - Scalar array
[ 'a':1, 'b':2 ] - Associative array
{ 'a':1, 'b':2 } - Stdclass object with properties a and b
of course the middle case is not valid json and then things break down a
bit. If we are going to support full json and then not be completely
compatible, why use the json syntax at all. And not supporting
associative arrays in the syntax is not an option.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
