Hi! > 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'd have encoder to ignore it. > 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. It's not actually a bug - as I said, nobody who knows anything about how computers do numbers expects exact representation of floats. That said, ability to *somehow* accept numbers which don't fit current precision may be useful in some corner cases, especially when you are interoperating with systems with different number sizes. As the old principle goes, be liberal in what you accept and conservative in what you produce. json_decode() option would fit this principle well. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
