Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61382
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKOpQSzMuQBv0MWZD0yHEg9bOt151F7_q0N_8jTMyDCKc7vzHA@mail.gmail.com>
References: <CAAyV7nFQc+4fWk2+aAJ_ctpqpsJGcYMR-fsgqDvPRzD36YJggg@mail.gmail.com>
	<DEA06CDBC7954435A74980C291F5F150@gmail.com>
	<CAN+gjSc=1fDHZHmJUya+QsDDdFOsbUr8CYhMVpFBV=qOOxGRQg@mail.gmail.com>
	<CAHHg72Ux+r41ApJWYUL5tO4vkKwrJAdbt+22zMNdRbX8X68LqA@mail.gmail.com>
	<CAKOpQSzMuQBv0MWZD0yHEg9bOt151F7_q0N_8jTMyDCKc7vzHA@mail.gmail.com>
Date: Tue, 17 Jul 2012 15:47:17 -0700
Message-ID: <CAKOpQSzNf91pW=psBpwu=RJuOO7JPRmabYtPDsx+Gm-HrYN_Vg@mail.gmail.com>
To: Dan Cryer <dan@dancryer.com>
Cc: Andrew Faulds <ajfweb@googlemail.com>, 
	Christoph Hochstrasser <christoph.hochstrasser@gmail.com>, internals@lists.php.net, 
	Anthony Ferrara <ircmaxell@gmail.com>
Content-Type: multipart/alternative; boundary=20cf3074b36818640b04c50e54e8
Subject: Re: [PHP-DEV] 6.0 And Moving Forward
From: kris.craig@gmail.com (Kris Craig)

--20cf3074b36818640b04c50e54e8
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jul 17, 2012 at 3:43 PM, Kris Craig <kris.craig@gmail.com> wrote:

>
>
> On Tue, Jul 17, 2012 at 8:48 AM, Dan Cryer <dan@dancryer.com> wrote:
>
>> >
>> > The problem, of course, is changing and removing things can break BC.
>> I'd
>> > love to remove list() too, but that would break code relying on it.
>>
>>
>> Isn't that kind of the point of the whole discussion? This is talking
>> about
>> completely rewriting the standard library for PHP 6, but providing a
>> legacy
>> extension/compile time option, which would bring with it almost complete
>> backwards compatibility with PHP 5.
>>
>>
> I think any reasonable person would expect there to be a significant
> number of BC breaks in any major version increment.  That being said,
> wouldn't it be possible in most of these cases to just do what we already
> do and use the E_DEPRECATED flag?  That way, people will have a reasonable
> amount of time to update their code to current standards before a behavior
> is removed completely.
>
> And in cases where E_DEPRECATED
>

Bah just had an unfortunate sequence of unintentional keystrokes....

As I was saying:

....And in cases where E_DEPRECATED wouldn't be feasible (such as with
changing function arguments), my thinking would be to just make the change
without having any legacy flags that have to be maintained.  Again, it's a
major version change.  Nobody should be getting butthurt over BC breaks.
 If you haven't updated your code since PHP 3, for example, my answer would
be to either update your code or stick with PHP 3.  The rest of us
shouldn't have to maintain inferior behavior-- especially in major version
increments-- just to accommodate those developers who refuse to keep their
code up-to-date.

--Kris

--20cf3074b36818640b04c50e54e8--