Re: Re: Deprecate PHP's short open tags, again

From: Date: Wed, 14 Aug 2019 08:39:33 +0000
Subject: Re: Re: Deprecate PHP's short open tags, again
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-106581@lists.php.net to get a copy of this message
On Wed, 14 Aug 2019 at 10:11, Rowan Collins <rowan.collins@gmail.com> wrote: > > On 13 August 2019 19:19:42 BST, Olumide Samson <hisamsonolu@gmail.com> wrote: > >Not sure what the counter argument is really driving at. > >So, because some people are using a function or an unworthy directive, > >then > >there can't be a major change in that aspect? > > > That's not what anyone is saying. What people are saying is that we shouldn't just > make changes because we feel like it; there should be a strong reason for the change. Most people > probably even agree up to that point, but disagree with whether the reasons given for this > particular case are strong enough. > > > >Not sure where this project is headed, some will want a code to stay > >because they want easy version upgrade(must everyone upgrade? ) and > >those > >who want to shake things up won't be allowed to do so. > > > I find it really frustrating that this feature, that most people had probably forgotten even > existed, has somehow been taken as an example of the pressing need for change. > > If you propose something that will actually take the language forward, but needs to break a few > things along the way, then you might have a valid complaint about lack of vision. But there is no > feature which will be unlocked by removing short tags; no big selling point we can talk about at > conferences; it will either work, or it won't, and most people's code will not be affected > one way or the other. > > Most people's wishlists for PHP, even some of the posts in this thread, include things > like generics, union types, enums, CoW classes/structs, annotations. To my knowledge, none of those > is currently being blocked by the need for backwards compatibility; most are being blocked because > they're hard to design, and hard to implement. > > The best counterargument I can give against "cleaning up" is that it takes energy > away from actual new features, even if it's just the mental energy of monitoring and responding > to long threads like this one. > > Regards, Code is like a garden. If there are unwanted weeds and nobody cleans them up, the flowers don't shine and grow as they should. Cleaning of the weeds is just as important as new features. A bit less but important. -- Peter Kokot

« previous php.internals (#106581) next »