On Tue, Jul 17, 2012 at 3:43 PM, Kris Craig <kris.cr...@gmail.com> wrote:
> > > On Tue, Jul 17, 2012 at 8:48 AM, Dan Cryer <d...@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
