Re: Throwing an E_DEPRECATED for short_open_tag

From: Date: Thu, 14 Jan 2010 21:54:24 +0000
Subject: Re: Throwing an E_DEPRECATED for short_open_tag
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to internals+get-46740@lists.php.net to get a copy of this message
Raphael Geissert wrote:
> Rasmus Lerdorf wrote:
> 
>> Raphael Geissert wrote:
>>> I'm still looking for a way to warn about the use of open_short_tag not
>>> being explicitly enabled on the PERDIR level. Otherwise the only thing I
>>> see would make applications change would be when the default is Off and
>>> they break.
>> But why do you want them to change?  Short tags are convenient and if
>> the app doesn't have to worry about <?xml or <?xsl type stuff, it can
>> run happily with short tags enabled.
> 
> Because it is just not about the application but the whole system. With the 
> apache filter SAPI enabling short_open_tag is really a no-op. As for the 
> other SAPIs it mostly depends on what kind of files are used and whether an 
> extension such as htscanner is at hand or not.
> 
> If that's not available, having to change the settings for every application 
> is a mess. By making it a runtime-only option they would always work.

A runtime option to turn them on would require a really ugly hack, or a
really ugly tag at the top of all short tag files like:

  <?php ini_set('short_open_tag',true)?>
  <?
    ...
  ?>

That doesn't seem like a very nice solution to me.  I think your goal of
making all apps run under the same config is a lost cause.  I know the
Gallery3 guys are very much sticking with the short_open_tag in their
new version, for example, and I don't blame them.

Wouldn't it make more sense to come up with a nice way of having per-app
configs instead?  Drop an app_name.conf file in a server config
directory and off you go.

-Rasmus


Thread (15 messages)

« previous php.internals (#46740) next »