Hi! > JSON_FLOAT_AS_STRING > decode: all float values will be decoded as string > - It's often an issue for very large float values with many fractional > digits that are coming from platforms that support larger float > representation than double. In that case the conversion is lost and there > is no way how to get it back (see http://bugs.php.net/68456 [pls ignore my > initial dump comments when I didn't get the issue :)] and an example of the > lost precision here http://3v4l.org/80iCh ). Converting the value to string > keep the precision and resolves the problem.
This makes sense, though one should be careful as string and float is not the same and if you re-encode it, you will have data corruption (since if somebody using, say, Java, decodes it they'd have string where it expects float and decoding will likely fail). But I guess since it is an option, people that enable it will have to deal with it, e.g. by never re-encoding the data back. > encode: all float values will be encoded as string > - re-using the constant for encoder makes sense if PHP creates JSON for > platform that support lower float type (e.g. C float) and the precision > loss is not acceptable Here I'm not sure it makes much sense though. If it's float, it should be float. It's valid JSON, so if the receiving side can not handle it, it's their issue which they have to fix in their decoding. Just changing the types of data when encoding JSON does not sound like a good idea. Especially given that the reader may be some library like Java's Jackson, where types are very important. Of course, we could add tons of options like INT_AS_STRING, OBJECT_AS_STRING, etc. but I don't think this is what json encoder should be doing. > I think that this is more a bugfix as the precision is lost without any way I don't see how it is a bugfix. Representing floats is imprecise, it is known and not a bug. json_encode now produces completely valid representation of the data, so no bug there either. I don't think changing value types on encoding is a good idea. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
