Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64013
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain roshambo.org from 209.85.220.42 cause and error)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <50AC75EE.60100@sugarcrm.com>
Date: Tue, 20 Nov 2012 22:50:05 -0800
Cc: Adam Harvey <aharvey@php.net>,
 PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Message-ID: <EFCBD0E2-5CB8-4BD0-A1BA-15771DE3B5ED@roshambo.org>
References: <23CB37F5-E956-4A5C-8ECC-7CF347A9086C@roshambo.org> <CAL+t6cF=2=vzfe2orVWo4NZ8N0akFfBOSKRdQg7nWBmTjphzsA@mail.gmail.com> <CAH-PCH5GOOt8LG70Anja3WDfWd5CHeJxZyScZD0WWMB2CEBZfg@mail.gmail.com> <CAL+t6cF+YEGb40dkV+FQZmDrLkT5PEMyQT2MEC=3uW83onbFBw@mail.gmail.com> <CAF+90c_ATMm_cJu_Ed4Rfn9_McVA=MtKun-LG+MZbqq8c_arUg@mail.gmail.com> <CAL+t6cFDZQEdOTr5G-1GZ6NAM-U6gphzt+42y6MhhmMKLxP8pg@mail.gmail.com> <CAF+90c8o9Vpqk4jz7kTPYycio_p-v+ck8v_Sr786G7Ud0xuL7A@mail.gmail.com> <F2DF6FC7-E254-4B0F-9136-5AAF050E9B9C@roshambo.org> <50AC6A7A.6030504@sugarcrm.com> <CADajX4Dhk8at4S-K0Yb3Bfmb100a0n11VfVneyt5DZMC7xviyA@mail.gmail.com> <50AC75EE.60100@sugarcrm.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Subject: Re: [PHP-DEV] Where did the _logo_ functions go?
From: philip@roshambo.org (Philip Olson)


On Nov 20, 2012, at 10:34 PM, Stas Malyshev wrote:

> 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.

We made sense, and are not being blind and stupid. You may disagree but
I don't understand why this discussion has to become so harsh.

>> 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.

It's the inconsistency that bothers me. I think a rule like "Never remove
a ~function without it first emitting E_DEPRECATED" can be followed 100% 
of the time, and don't see this as a bureaucratic rule but instead think
this consistency would make PHP better.

Regards,
Philip