On Wed, 24 Jul 2019 at 13:21, Nikita Popov <nikita....@gmail.com> wrote:
> On Tue, Jul 23, 2019 at 11:40 PM Peter Cowburn <petercowb...@gmail.com> > wrote: > >> >> >> On Tue, 23 Jul 2019 at 22:03, Nikita Popov <nikita....@gmail.com> wrote: >> >>> On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins <rowan.coll...@gmail.com> >>> wrote: >>> >>> > On 23 July 2019 18:54:48 BST, "G. P. B." <george.bany...@gmail.com> >>> wrote: >>> > >The only point of contention of this RFC that I potentially see is the >>> > >removal in PHP 8.1 after short open tags being a Parse Error in PHP >>> 8.0 >>> > >instead of it being removed in PHP 9 after it having had a whole major >>> > >version release cycle. >>> > >>> > Given that you've already predicted that this will be controversial, >>> could >>> > you provide some rationale for it? Unless there's a major burden in >>> > maintaining the parser error behaviour for a few years, waiting for the >>> > next major version would seem both safer and more in line with official >>> > versioning policy. >>> > >>> > As with deprecation itself, any violation of the "no breaking changes" >>> > rule, however slight, should have an explicit justification. If I had a >>> > vote, any RFC omitting such a justification would receive an automatic >>> "no" >>> > from me. >>> > >>> >>> I agree. I don't think there's a pressing need to do the "full removal" >>> in >>> PHP 8.1 in particular, so it makes more sense to this in the next major >>> version (9.0), as usual. >>> >>> Nikita >>> >> >> Would you (George, Nikita) consider removing the details about the >> eventual removal of the feature from this RFC? We can run with the error >> for a bunch of releases / years, and see what happens. I don't see why we >> should necessarily decide now on something that might be 5 years or more >> away. >> > > I don't see a benefit in leaving this open-ended and prefer to have a > fixed timeline for this. The full removal in 9.0 is already very, very > conservative. Using short tags will have produced a fatal error for a whole > major version at that point. If necessary the question can be reevaluated > at that time, but the burden of proof must be on the people arguing an > additional delay, not the other way around. > Hypothetically, it can be re-evaluated sooner, particularly if "everyone" in the PHP ecosystem appears to respond very well once the deprecation and error stages happen. In fact, I wouldn't want "but we voted for 9.0" to be a point being made if/when that discussion comes along. My point is that the removal release/date, in my opinion, is a detail that we don't need to be concerned with right now and it's just adding noise. You disagree, and that's totally okay. > > Nikita >
