I don't think this problems calls for a more flexible solution. On the
other hand I think the flexibility _is_ the problem. Today if I want
to write compatible php code I can neither use:
<?foreach($rows as $row):?> ...
or
<?xml ...
in my template files. Bummer! :)
I would much prefer that one and only one tag setting was chosen as
the official one and that a very slow deprecation path was taken so we
in the end could remove the other ones. One less thing to think about.
On Thu, May 19, 2011 at 4:55 PM, Keloran <ava...@gmail.com> wrote:
> I like the idea of having an option for no tags needed, since its a .php
> file (or what ever you have set as your interpd name) that gets sent to the
> interpreter anyway, it shouldnt really need opening tag,
>
> the only thing of this that i dont like is the runtime side of it, imo that
> shouldnt be an option
>
> On Thu, May 19, 2011 at 3:39 PM, Michael Morris <dmgx.mich...@gmail.com>wrote:
>
>> Some time ago I floated this idea without any traction. I wanted to make an
>> RFC but never got any help in setting up an account to submit it. Here it
>> is again:
>>
>> Tag style can be set from the ini file, htaccess/httpdconfig or changed at
>> runtime. If changed at runtime it only affects files that haven't been
>> included yet. Tag Style can also be passed as the second argument to the
>> include, include_once, require, and require_once statements. Those
>> statements fall back to the current setting if a second argument isn't
>> passed. The tag style is a bitfield as follows:
>>
>> Bit
>> 0 -- Standard tags toggle
>> 1 -- Short tags toggle
>> 2 -- ASP tags toggle
>> 3 -- Script tags toggle
>> 4 -- Short echo toggle.
>>
>> For backwards compat ship with bits 0 and 3 set on. The existing short tags
>> mode is bits 1 and 4 on. If all the bits are turned off then we have the
>> PHP_TAGS_NONE setting. In that mode the engine assumes the whole file is
>> going to be PHP code since there will be no tags at all (helpful for class
>> libraries that don't create output in the MVC architecture).
>>
>> If the php.ini file has either of the legacy tag settings turned on, and
>> tag_style wasn't explicitly set, then php will set tag style to the values
>> it must have to mimic the intent of the setting. If tag_style is explicitly
>> set then it wins out - but a deprecated notice gets thrown to alert the
>> user
>> that they have both tag_style set and short_open_tags and/or asp_tags set
>> on.
>>
>> If an htaccess or httpd.conf directive explicitly calls for short_tags or
>> asp_tags after tag_style was explicitly set a warning of some sort is
>> thrown
>> informing the user that they must switch that declaration to one compatible
>> with the php.ini file.
>>
>> The upshot of this is to allow distributions that want to use short tags to
>> be able to use them without worrying about local server settings. Also,
>> distributions can be made to contain files without any tags at all.
>> Teaching IDE's that it is possible for a PHP file to have no <?php ?> tags
>> could be tricky though.
>>
>> On Thu, May 19, 2011 at 3:23 AM, Arvids Godjuks <arvids.godj...@gmail.com
>> >wrote:
>>
>> > It's essentially the same what I said - move it out of stort_tags and
>> > make it "On" permanently.
>> >
>> > As I remember the decision to remove short_tags was made together with
>> > register_globals, magic_quotes and other legacy stuff. I can be that I
>> > remember wrongly, but really do people really use <% ?
>> >
>> > 2011/5/19 Ferenc Kovacs <i...@tyrael.hu>:
>> > >
>> > >
>> > > On Thu, May 19, 2011 at 8:53 AM, Arvids Godjuks <
>> > arvids.godj...@gmail.com>
>> > > wrote:
>> > >>
>> > >> Hello.
>> > >>
>> > >> As a userland developer i'm all for it. Remove short_tags and decouple
>> > >> <?= from them to be in PHP core always on.
>> > >>
>> > >
>> > > I think that it's a little bit hasty.
>> > > I would propose that the short open echo should be always enabled
>> > > independently from the short_open_tag, and this should be documented
>> and
>> > > done with it.
>> > > Tyrael
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
