Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:53499 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 19717 invoked from network); 22 Jun 2011 00:37:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Jun 2011 00:37:01 -0000 Authentication-Results: pb1.pair.com header.from=j.boggiano@seld.be; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=j.boggiano@seld.be; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain seld.be designates 209.85.214.42 as permitted sender) X-PHP-List-Original-Sender: j.boggiano@seld.be X-Host-Fingerprint: 209.85.214.42 mail-bw0-f42.google.com Received: from [209.85.214.42] ([209.85.214.42:63471] helo=mail-bw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CC/62-25945-A29310E4 for ; Tue, 21 Jun 2011 20:37:00 -0400 Received: by bwz18 with SMTP id 18so381326bwz.29 for ; Tue, 21 Jun 2011 17:36:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.126.36 with SMTP id a36mr46790bks.44.1308703014502; Tue, 21 Jun 2011 17:36:54 -0700 (PDT) Received: by 10.204.113.70 with HTTP; Tue, 21 Jun 2011 17:36:54 -0700 (PDT) In-Reply-To: <4E0135CE.6090908@sugarcrm.com> References: <4DFF7C28.30100@sugarcrm.com> <4E0135CE.6090908@sugarcrm.com> Date: Wed, 22 Jun 2011 02:36:54 +0200 Message-ID: To: Stas Malyshev Cc: "internals@lists.php.net" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] Changed behaviour for strtr() From: j.boggiano@seld.be (Jordi Boggiano) On Wed, Jun 22, 2011 at 2:22 AM, Stas Malyshev wrote: >> Right now strtr('anything', 'anything', '') === 'anything', which >> means that anyone relying on this behavior is doing something strange >> and dumb imo, doing a function call for nothing. We could maybe say > > It does not matter if you approve or disapprove how people write their code > - we can't break BC unless there's a VERY good reason. You never know in > which situation with which combination of inputs which application may end > up using this sequence of parameters and how changing it may break it. Of course it's not just a matter of taste, but the null case imo really is not likely to happen by accident, and there is no valid use case. Anyways.. Case closed I suppose. Cheers -- Jordi Boggiano @seldaek :: http://seld.be/