Hi! > foot, by discarding possibly important information when serialising - an > operation that's supposed to perfectly reproduce a value!
I'm not sure this is correct. Also, for values that are not exactly representable in binary, I'm not sure you want to see 0.1000000000000000055511151231257827021181583404541015625 instead of 0.1. You certainly don't want var_dump to print that by default - this would make display cluttred and have very high WTF factor - why I entered 0.1 and get this enormous snake of a number? PHP must be broken! Moreover, when you do "$a = 8.2 - 0.2" and then print/send $a, do you want to see 8 or 7.99999999999999911182158029987476766109466552734375? In fact, when we represent 0.1 as 0.1 when serializing our outputting, we are not discarding information, on the contrary - we are preserving exactly the information that was given to us by user. > print floats to their full precision - including in var_dump(). This can > create unreasonable confusion when debugging (why are two numbers that > appear identical with var_dump() reported as inequal?), means You really think that displaying 8.2 - 0.2 as 8 is more confusing than displaying it as 7.99999999999999911182158029987476766109466552734375? > potentially important information is removed by default, and really > ought not to be a global setting anyway: if you want to format your > numbers with reduced precision, do so explicitly. That would mean optimizing for case that nobody wants, and de-optimizing case that pretty much everybody wants. Ask 100 people using PHP what they want as a result of 8.2 - 0.2 and count how many of them want to see full-precision monster of a number. > There might be others worth dealing with, too, these are just the first > three I thought of. I would very much advise not to mess with any options until we are definitely, 100%, without any doubt sure that nobody needs to use it for anything. Removing options earns us nothing in terms of functionality. If nobody uses them - ok, fine - drop them. If we need to remove them e.g. because component they address goes away or changes function in a way that makes it irrelevent - fine, drop them. But doing it just because very small number of people that we can engage in discussion on the list (and that's not going to ever change - PHP user community is vastly larger than people even reading this list, let alone actively participating in it) think it's not needed IMHO is a very wrong approach. Sometimes we have no choice but to take decisions with this incomplete knowledge - but here we have a perfectly good option of just leaving it alone. All other options should be weighted against it. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
