Re: Re: [RFC] Deprecations for PHP 7.1
| From: | Stanislav Malyshev | Date: | Wed, 24 Feb 2016 00:48:18 +0000 |
| Subject: | Re: Re: [RFC] Deprecations for PHP 7.1 | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-91366@lists.php.net to get a copy of this message | ||
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
smalyshev@gmail.com