On 17 January 2015 at 13:38, César Rodas <ce...@rodas.me> wrote: > Hi Pierre! > > On 17/01/15 08:02, Pierre Joye wrote: > > On Jan 17, 2015 5:58 PM, "Tony Marston" <tonymars...@hotmail.com> wrote: > >> > >> "Stelian Mocanita" wrote in message > >> news:camc0ws5lpdvqf_5p8uiwbzuqc+max+shmmi8pzlggrfoj7a...@mail.gmail.com. > .. > >>> > >>> > >>> Florian Margaine wrote on 16/01/2015 13:01: > >>> > >>> Hi Stelian, > >>>> > >>>> > >>>> Stelian Mocanita writes: > >>>> > >>>> Not under active development doesn't mean that the application > shouldn't > >>>> be able to upgrade PHP and enjoy the bug/security fixes or performance > >>>> improvements that new versions provide. > >> > >> > >> I agree. If the core developers want each new release, with its bug > fixes > >> and security enhancements, to be adopted by the community then they > should > >> stop breaking BC for no good reason. > > > > Can wie stop using this argument pls? > > > > We are talking about something deprecated since 10 years, about the 1st > > major release in a decade, something we will use for the next 12-14 > years. > > > > 5.x will be maintained as well for the next 3 years (plus distros LTS). > We > > do not break BC since quite some time too in minor releases. > > > > Cheers, > > Pierre > > > > Wouldn't be better if we borrow things from Perl? I mean, we have an > 'strict mode' (`use strict;` perhaps) where deprecated things doesn't > work at all and they throw exceptions (such as the old PH4 constructors > for instance). > > In this case, I think that would actually be the worst of both worlds - support for PHP 4 constructors would still need to be maintained in core, with extra logic for handling the mode switch. Meanwhile, people using old code with old constructors would never turn strict mode on, and people who turn strict mode on are probably already well aware that they should be using __construct.
Annoying though it would be to receive dozens of them, I think issuing an E_DEPRECATED notice when such constructors are defined is probably the best approach for now. It does once again make me want medically scoped error reporting, though (e.g. ignore E_DEPRECATED and E_NOTICE raised in this PEAR module which I am phasing out anyway) -- Rowan Collins [IMSoP]
