On Tue, 20 Aug 2019 at 18:39, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > On 20/08/2019 17:18, Peter Kokot wrote: > > About the docs - there are > > very minor changes needed where "backwards compatibility" is mentioned > > maybe. Because they are not in PHP for keeping BC anymore now. Nobody > > proposed a better solution than this RFC, then they are a feature. > > > Being "for Backwards Compatibility" and being "there forever" are not > mutually exclusive. There are a huge number of things in this world > which exist only to be compatible with an older technology or use case, > but which will never be phased out, because the effort to change them > exceeds the benefit. > > On the other hand, I think it might be useful to have a status of > "officially discouraged" distinct from "deprecated". I occasionally hear > people ask to "deprecate" something without any particular timeline or > criteria for when it would be removed; my suspicion is that what they > really want is a clearer message to users that they shouldn't use the > feature. > > Regards,
Probably. But fact is that PHP opening short tags can be used. We can enable them in controlled environments and use the short tags knowing they will never be removed now. No deprecation warning is standing in our way to do that now. And such code (or better put app) is honestly now also not so bad. Because it will still work in at least let's say, PHP 9 at least or considering the feedback and discussions for ever... Also users who are already using short tags can now postpone the upgrades for another ~5+ years at least :) -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
