Re: Alternative approach to short tags deprecation

Hello, On Thu, 25 Apr 2019 at 09:15, Nikita Popov <nikita.ppv@gmail.com> wrote: > > Hi internals, > > As already discussed in the corresponding voting thread, the deprecation of > short tags as proposed has a high risk of causing inadvertent source code > leakage. The RFC proposes to change the default of short_open_tag from On > to Off in PHP 7.4. Any website using short_open_tags without explicitly > enabling it (relying on the default) will leak source code unless proper > precautions are taken before switching to PHP 7.4. > > Disregarding the question of whether short tags should be removed at all > (let's keep that question in the other thread), I do think we need to > reconsider the deprecation approach. In particular, I would like to propose: > > In PHP 7.4: > * The default value of short_open_tag remains as is and enabling > short_open_tag does not generate a deprecation warning (otherwise PHP would > warn in a default config). > * If short_open_tag is enabled: The first use of <? generates a > deprecation warning. (Potentially every use could throw a deprecation, but > generally, if <? is used, it's used a lot and this would cause a lot of > noise in the error log.) > * If short_open_tag is disabled: <? is considered normal text. > > In PHP 8.0: > * The default value of short_open_tag remains as is and enabling > short_open_tag does not generate a deprecation warning or error. > * If short_open_tag is enabled: Any use of <? generates a compile error. > * If short_open_tag is disabled: <? is considered normal text. > > At a later point in time: > * The short_open_tag option is removed. > * <? is always considered normal text. > > The advantage of such an approach would be that no source code leakage > could occur when switching to PHP 7.4 or PHP 8.0. The disadvantage is that > we'll only be able to fully remove short tags support at a later point in > time. > > Thoughts? > > Regards, > Nikita Sure. I think we can do that also for people who haven't upgraded their code yet and can do that at their own pace by ~ 2025/2026. By that time the rest of us will be using "Jitted", "asynced", more consistent, and slick-syntaxed PHP everywhere already so they can catch us up... :) No worries. The approach described sounds ok to me. Would be also good to think even more in advance - like making <?php opening tag optional in source code files only etc. So we can write a class file without opening PHP tag at all and similar syntactical sugars. That would be really neat I think. Cheers. -- Peter Kokot