Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:64011 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 18546 invoked from network); 21 Nov 2012 06:34:27 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Nov 2012 06:34:27 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 173.203.6.139 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 173.203.6.139 smtp139.ord.emailsrvr.com Linux 2.6 Received: from [173.203.6.139] ([173.203.6.139:37427] helo=smtp139.ord.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 03/D4-20662-2F57CA05 for ; Wed, 21 Nov 2012 01:34:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp10.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id F00DC37009F; Wed, 21 Nov 2012 01:34:23 -0500 (EST) X-Virus-Scanned: OK Received: by smtp10.relay.ord1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 73F63370096; Wed, 21 Nov 2012 01:34:23 -0500 (EST) Message-ID: <50AC75EE.60100@sugarcrm.com> Date: Tue, 20 Nov 2012 22:34:22 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adam Harvey CC: Philip Olson , PHP Developers Mailing List References: <23CB37F5-E956-4A5C-8ECC-7CF347A9086C@roshambo.org> <50AC6A7A.6030504@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Where did the _logo_ functions go? From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > The issue I have with this is just that we don't seem to be making > much of an effort to stick to the promises we've made around BC when We make a lot of effort to do this. But it does not mean we should be blindly and stupidly following the rigid rules even when it makes zero sense in practice. > it doesn't suit us to. I agree: in practice, I can't imagine anyone > caring a jot about these functions being removed, but we've said that > when we're going to remove something, we'll deprecate for a minor > release, then remove. Why don't we live up to it? Exactly because in practice it is not important. So on one side, you have making PHP better without any practical downside. On the other side, you have delaying making PHP better, but feeling good about strictly following bureaucratic rules. I prefer the former. Rules are important, but it is also important to not lose the sight of the goal - why these rules exist and when they make sense. And when they don't. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227