Hi Stas On Wed, Apr 1, 2015 at 7:58 AM, Stanislav Malyshev <smalys...@gmail.com> wrote: > > > > 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. > > The encoding was just about re-using it. I wouldn't probably propose such constant if it was just for encoding (the main purpose is decoding though). I just thought that it could be a good idea to have some usage for encoder if it's added. It seemed to me better than just ignore it completely for encoder. What do you think?
> > 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. > > I didn't mean it for json_encode ( apology for that as it might have seemed that is related just to json_encode). I meant it just as "a sort of" bug for json_decode as we loose information without giving user any way how to prevent it or at least some note in documentation about that. Cheers Jakub
