Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91366
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.172 as permitted sender)
To: Andrea Faulds <ajf@ajf.me>, internals@lists.php.net
References: <CAF+90c_1zO91x-4Madqm3F8gkKDT7jZKVZSbBuYMbnDCADrv_A@mail.gmail.com>
 <47.95.38634.798BCC65@pb1.pair.com>
Message-ID: <56CCFDD2.4000102@gmail.com>
Date: Tue, 23 Feb 2016 16:48:18 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <47.95.38634.798BCC65@pb1.pair.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1
From: smalyshev@gmail.com (Stanislav Malyshev)

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