Re: Re: Deprecate PHP's short open tags, again
| From: | Peter Kokot | 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