Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96386 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 27889 invoked from network); 16 Oct 2016 08:01:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Oct 2016 08:01:42 -0000 Authentication-Results: pb1.pair.com smtp.mail=lauri.kentta@gmail.com; spf=softfail; sender-id=softfail Authentication-Results: pb1.pair.com header.from=lauri.kentta@gmail.com; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain gmail.com does not designate 188.117.41.47 as permitted sender) X-PHP-List-Original-Sender: lauri.kentta@gmail.com X-Host-Fingerprint: 188.117.41.47 mailgateway.locotech.fi Linux 2.6 Received: from [188.117.41.47] ([188.117.41.47:41900] helo=mailgateway.locotech.fi) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 62/27-59423-3E333085 for ; Sun, 16 Oct 2016 04:01:40 -0400 Received: from localhost (mailgateway [127.0.0.1]) by mailgateway.locotech.fi (Postfix) with ESMTP id 3071BA36C27; Sun, 16 Oct 2016 11:01:36 +0300 (EEST) X-Virus-Scanned: amavisd-new at locotech.fi X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-9998 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9] autolearn=no autolearn_force=no Received: from mailgateway.locotech.fi ([127.0.0.1]) by localhost (mailgateway.locotech.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OLviwsGGM36m; Sun, 16 Oct 2016 11:01:24 +0300 (EEST) Received: from posti.fimnet.fi (posti.fimnet.fi [172.16.1.44]) by mailgateway.locotech.fi (Postfix) with ESMTP id 39EDDA36C52; Sun, 16 Oct 2016 11:01:23 +0300 (EEST) Received: from k-piste.dy.fi (unknown [172.16.1.39]) by posti.fimnet.fi (Postfix) with ESMTPSA id 1BA08101D57; Sun, 16 Oct 2016 11:01:23 +0300 (EEST) Received: from localhost.localdomain ([::1] helo=k-piste.dy.fi) by k-piste.dy.fi with esmtp (Exim 4.87) (envelope-from ) id 1bvgNm-0007Qy-QF; Sun, 16 Oct 2016 11:01:22 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sun, 16 Oct 2016 11:01:22 +0300 To: Stanislav Malyshev Cc: Yasuo Ohgaki , Niklas Keller , PHP Internals In-Reply-To: References: <12ecd7d8-2c72-d835-a1af-20698ee9885c@gmail.com> <19522e77-7084-57e7-1fb1-e31b1f9d3c89@gmail.com> <5023d189-21de-93a0-b2fc-8fae77fbbe48@gmail.com> <286fe3084638521a3273df037b602ae0@koti.fimnet.fi> Message-ID: <4fb9192ad141f555c20e3e09ae50775d@gmail.com> X-Sender: lauri.kentta@gmail.com User-Agent: Roundcube Webmail/1.2.2 Subject: Re: [PHP-DEV] wordwrap with negative width From: lauri.kentta@gmail.com (=?UTF-8?Q?Lauri_Kentt=C3=A4?=) On 2016-10-16 03:28, Stanislav Malyshev wrote: > Hi! > >> Keeping the current behavior doesn't really cost anything. >> Why change it? > > I think I answered this question several times, including in the email > you are quoting! If you disagree, please state the matter of your > disagreement, repeating the same question over and over does not help. To be clear: I'm not agains the warning, I'm against the false. I don't seem to find any other "answer" than your personal opinion that the old behavior "doesn't make sense". That's not a real answer. Zero width doesn't make sense either, so are you going to remove that as well? There are a lot of things in PHP that don't make sense, and you can't remove them all. I'll rephrase the question: Suppose you add the warning anyway. What do you gain by returning false? Is there an additional benefit? >> It's very easy to imagine a script like this: >> >> > $text_width = $parent_width - $other_width - $margin; >> echo wordwrap($text, $text_width); >> ?> >> >> Here someone tries to calculate $max_width dynamically. >> The calculation might produce a negative result sometimes. >> The text would be visible, even if it's not word wrapped. >> It might not look as expected, but it would be readable. > > If it was expected to be wrapped but is not, then it would be shown on > top of other elements, or break the design layout. Not exactly the best > idea. Since calling it with negative argument makes no sense, there's > no > behavior that makes sense. Producing an error means this nonsense > situation is discovered. If it was seriously breaking their layout, they would fix it anyway. Or they would say, "oh well, at least the text is readable!" So let's suppose it currently works "well enough". You get your patch in, and suddenly some text magically disappears. They might not see the warning (old scripts often disable warnings), so they might not know at all why the text is gone. They just tried to upgrade PHP (or their sevice provider did), and now it's broken. OTOH, if you only add the warning, some people may even fix their code, others might not, and it doesn't really matter. Also, if/when you document that negative width is no longer supported, soon people will discover the easy fix, max($width,0), and you have really gained nothing but more hacks in bad code. -- Lauri Kenttä