Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] RFC: source files without opening tag

Posted by Tom Boutell 
Tom Boutell
[PHP-DEV] RFC: source files without opening tag
April 08, 2012 06:40PM
I have written an RFC proposing backwards-compatible support for
source files without an opening <?php tag:

https://wiki.php.net/rfc/source_files_without_opening_tag

This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
what the requirements are to get it added to the "Under Discussion"
session and get the ball rolling formally. Please enlighten and I'll
do whatever is required.

Thanks!

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kris Craig
Re: [PHP-DEV] RFC: source files without opening tag
April 08, 2012 11:20PM
As far as I know, you've already met that req by posting the RFC here, so
go ahead and add it. In the future, remember there's also an "In Draft"
status for RFCs that haven't been announced here yet. :)
On Apr 8, 2012 9:32 AM, "Tom Boutell" <[email protected]> wrote:

> I have written an RFC proposing backwards-compatible support for
> source files without an opening <?php tag:
>
> https://wiki.php.net/rfc/source_files_without_opening_tag
>
> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
> what the requirements are to get it added to the "Under Discussion"
> session and get the ball rolling formally. Please enlighten and I'll
> do whatever is required.
>
> Thanks!
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Tom Boutell
Re: [PHP-DEV] RFC: source files without opening tag
April 08, 2012 11:30PM
I don't think I have the privilege of editing the main page that lists
all the RFCs.

The template should probably say "In Draft" rather than starting out
with the wrong status (:

On Sun, Apr 8, 2012 at 5:10 PM, Kris Craig <[email protected]> wrote:
> As far as I know, you've already met that req by posting the RFC here, so go
> ahead and add it.  In the future, remember there's also an "In Draft" status
> for RFCs that haven't been announced here yet.  :)
>
> On Apr 8, 2012 9:32 AM, "Tom Boutell" <[email protected]> wrote:
>>
>> I have written an RFC proposing backwards-compatible support for
>> source files without an opening <?php tag:
>>
>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>
>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>> what the requirements are to get it added to the "Under Discussion"
>> session and get the ball rolling formally. Please enlighten and I'll
>> do whatever is required.
>>
>> Thanks!
>>
>> --
>> Tom Boutell
>> P'unk Avenue
>> 215 755 1330
>> punkave.com
>> window.punkave.com
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yasuo Ohgaki
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 12:00AM
Hi,

Moriyoshi has created same entry on 4/1, but
it seems it was deleted already.

Anyway, he had a patch for it.

https://gist.github.com/2266652

As I mentioned in other thread, we should better to have
a switch to disable embed mode for security reasons.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net



2012/4/9 Tom Boutell <[email protected]>:
> I have written an RFC proposing backwards-compatible support for
> source files without an opening <?php tag:
>
> https://wiki.php.net/rfc/source_files_without_opening_tag
>
> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
> what the requirements are to get it added to the "Under Discussion"
> session and get the ball rolling formally. Please enlighten and I'll
> do whatever is required.
>
> Thanks!
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> 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
Yasuo Ohgaki
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 12:00AM
Hi,

There is RFC that is written by Moriyoshi.
It's not listed in RFC page, though.

https://wiki.php.net/rfc/nophptags

I think these should be merged.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net



2012/4/9 Yasuo Ohgaki <[email protected]>:
> Hi,
>
> Moriyoshi has created same entry on 4/1, but
> it seems it was deleted  already.
>
> Anyway, he had a patch for it.
>
> https://gist.github.com/2266652
>
> As I mentioned in other thread, we should better to have
> a switch to disable embed mode for security reasons.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
>
>
> 2012/4/9 Tom Boutell <[email protected]>:
>> I have written an RFC proposing backwards-compatible support for
>> source files without an opening <?php tag:
>>
>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>
>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>> what the requirements are to get it added to the "Under Discussion"
>> session and get the ball rolling formally. Please enlighten and I'll
>> do whatever is required.
>>
>> Thanks!
>>
>> --
>> Tom Boutell
>> P'unk Avenue
>> 215 755 1330
>> punkave.com
>> window.punkave.com
>>
>> --
>> 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
Tom Boutell
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 12:30AM
Moriyoshi was kidding, as near as I can tell (:

To take it at face value though, the *cough* April 1st *cough*
proposal of Moriyoshi calls for the complete abolition of the feature
with no backwards compatibility with existing code that uses PHP as a
template language... including most popular frameworks that sensibly
obey a separation between class files and template files but still use
PHP rather than a dedicated templating language for templates.

I don't think that's realistic (and neither did the author it
appears). Since PHP's usability as a template language may conceivably
be improved by other proposals, it is undesirable as well even if you
don't currently find PHP to be a suitable template language.

Please read my proposal over carefully as it does address the obvious
issues that make Moriyoshi's proposal possibly less than serious in
intent (:

I would oppose a php.ini flag for this as that gives us two
incompatible versions of the current version of the language to worry
about and makes the feature effectively unusable in reusable code.
This approach has created problems before.

On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki <[email protected]> wrote:
> Hi,
>
> There is RFC that is written by Moriyoshi.
> It's not listed in RFC page, though.
>
> https://wiki.php.net/rfc/nophptags
>
> I think these should be merged.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
>
>
> 2012/4/9 Yasuo Ohgaki <[email protected]>:
>> Hi,
>>
>> Moriyoshi has created same entry on 4/1, but
>> it seems it was deleted  already.
>>
>> Anyway, he had a patch for it.
>>
>> https://gist.github.com/2266652
>>
>> As I mentioned in other thread, we should better to have
>> a switch to disable embed mode for security reasons.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohgaki@ohgaki.net
>>
>>
>>
>> 2012/4/9 Tom Boutell <[email protected]>:
>>> I have written an RFC proposing backwards-compatible support for
>>> source files without an opening <?php tag:
>>>
>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>
>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>>> what the requirements are to get it added to the "Under Discussion"
>>> session and get the ball rolling formally. Please enlighten and I'll
>>> do whatever is required.
>>>
>>> Thanks!
>>>
>>> --
>>> Tom Boutell
>>> P'unk Avenue
>>> 215 755 1330
>>> punkave.com
>>> window.punkave.com
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yasuo Ohgaki
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 12:50AM
Hi,

I talked on twitter.
Yes, he is kidding, but he is serious, too.

I've added the RFC to Under Discussion and added
security issue description. I also added my proposal that
controls embed mode.

BTW, I don't think we need new "require_path" why don't
we use

require "file.php", ture;

or some thing similar?
I prefer to use switch, since security countermeasure is
better to be enforced by switch.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net



2012/4/9 Tom Boutell <[email protected]>:
> Moriyoshi was kidding, as near as I can tell (:
>
> To take it at face value though, the *cough* April 1st *cough*
> proposal of Moriyoshi calls for the complete abolition of the feature
> with no backwards compatibility with existing code that uses PHP as a
> template language... including most popular frameworks that sensibly
> obey a separation between class files and template files but still use
> PHP rather than a dedicated templating language for templates.
>
> I don't think that's realistic (and neither did the author it
> appears). Since PHP's usability as a template language may conceivably
> be improved by other proposals, it is undesirable as well even if you
> don't currently find PHP to be a suitable template language.
>
> Please read my proposal over carefully as it does address the obvious
> issues that make Moriyoshi's proposal possibly less than serious in
> intent (:
>
> I would oppose a php.ini flag for this as that gives us two
> incompatible versions of the current version of the language to worry
> about and makes the feature effectively unusable in reusable code.
> This approach has created problems before.
>
> On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki <[email protected]> wrote:
>> Hi,
>>
>> There is RFC that is written by Moriyoshi.
>> It's not listed in RFC page, though.
>>
>> https://wiki.php.net/rfc/nophptags
>>
>> I think these should be merged.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohgaki@ohgaki.net
>>
>>
>>
>> 2012/4/9 Yasuo Ohgaki <[email protected]>:
>>> Hi,
>>>
>>> Moriyoshi has created same entry on 4/1, but
>>> it seems it was deleted  already.
>>>
>>> Anyway, he had a patch for it.
>>>
>>> https://gist.github.com/2266652
>>>
>>> As I mentioned in other thread, we should better to have
>>> a switch to disable embed mode for security reasons.
>>>
>>> Regards,
>>>
>>> --
>>> Yasuo Ohgaki
>>> yohgaki@ohgaki.net
>>>
>>>
>>>
>>> 2012/4/9 Tom Boutell <[email protected]>:
>>>> I have written an RFC proposing backwards-compatible support for
>>>> source files without an opening <?php tag:
>>>>
>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>>
>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>>>> what the requirements are to get it added to the "Under Discussion"
>>>> session and get the ball rolling formally. Please enlighten and I'll
>>>> do whatever is required.
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> Tom Boutell
>>>> P'unk Avenue
>>>> 215 755 1330
>>>> punkave.com
>>>> window.punkave.com
>>>>
>>>> --
>>>> PHP Internals - PHP Runtime Development Mailing List
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>
>
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> 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
Tom Boutell
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 01:20AM
Thanks. However, would you please fix the summary on the RFC's page to
match the summary in the actual RFC? As you have written it, it
implies that support for <?php would be completely removed. This is
not the case.

As for adding a boolean parameter to the require keyword, as the RFC
mentions there are already at least two distinctions already when
requiring files in PHP:

* include vs. require behavior (warning vs. error on failure)
* once vs. every time (require_once vs. require)

And we are proposing a third:

* start in php mode vs. start in html mode

We already have four keywords for requiring files. At this point it
does not make sense to keep introducing more keywords (we would need 8
with this change). Your boolean flag proposal keeps it to four
keywords, but as soon as someone adds another flag it will become
awkward to remember them. Since PHP does not have named parameters I
think an associative array is the best way to go (especially with the
new short syntax).

Also I don't think it makes sense to forbid shifting into html mode
later in the file, it could reduce support for the proposal needlessly
- since it already lets people who want to write clean all-PHP files
do so, and some of those people might have legitimate reasons to use
HTML mode in the scope of a function or method (where it does not
suddenly introduce whitespace without being explicitly called, etc).

But if it really came down to it I could live with an "absolutely
nothing but PHP" behavior when the code flag is true (supporting <?php
when the flag is not set is a must of course).

On Sun, Apr 8, 2012 at 6:45 PM, Yasuo Ohgaki <[email protected]> wrote:
> Hi,
>
> I talked on twitter.
> Yes, he is kidding, but he is serious, too.
>
> I've added the RFC to Under Discussion and added
> security issue description. I also added my proposal that
> controls embed mode.
>
> BTW, I don't think we need new "require_path" why don't
> we use
>
> require "file.php", ture;
>
> or some thing similar?
> I prefer to use switch, since security countermeasure is
> better to be enforced by switch.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
>
>
> 2012/4/9 Tom Boutell <[email protected]>:
>> Moriyoshi was kidding, as near as I can tell (:
>>
>> To take it at face value though, the *cough* April 1st *cough*
>> proposal of Moriyoshi calls for the complete abolition of the feature
>> with no backwards compatibility with existing code that uses PHP as a
>> template language... including most popular frameworks that sensibly
>> obey a separation between class files and template files but still use
>> PHP rather than a dedicated templating language for templates.
>>
>> I don't think that's realistic (and neither did the author it
>> appears). Since PHP's usability as a template language may conceivably
>> be improved by other proposals, it is undesirable as well even if you
>> don't currently find PHP to be a suitable template language.
>>
>> Please read my proposal over carefully as it does address the obvious
>> issues that make Moriyoshi's proposal possibly less than serious in
>> intent (:
>>
>> I would oppose a php.ini flag for this as that gives us two
>> incompatible versions of the current version of the language to worry
>> about and makes the feature effectively unusable in reusable code.
>> This approach has created problems before.
>>
>> On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki <[email protected]> wrote:
>>> Hi,
>>>
>>> There is RFC that is written by Moriyoshi.
>>> It's not listed in RFC page, though.
>>>
>>> https://wiki.php.net/rfc/nophptags
>>>
>>> I think these should be merged.
>>>
>>> Regards,
>>>
>>> --
>>> Yasuo Ohgaki
>>> yohgaki@ohgaki.net
>>>
>>>
>>>
>>> 2012/4/9 Yasuo Ohgaki <[email protected]>:
>>>> Hi,
>>>>
>>>> Moriyoshi has created same entry on 4/1, but
>>>> it seems it was deleted  already.
>>>>
>>>> Anyway, he had a patch for it.
>>>>
>>>> https://gist.github.com/2266652
>>>>
>>>> As I mentioned in other thread, we should better to have
>>>> a switch to disable embed mode for security reasons.
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Yasuo Ohgaki
>>>> yohgaki@ohgaki.net
>>>>
>>>>
>>>>
>>>> 2012/4/9 Tom Boutell <[email protected]>:
>>>>> I have written an RFC proposing backwards-compatible support for
>>>>> source files without an opening <?php tag:
>>>>>
>>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>>>
>>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>>>>> what the requirements are to get it added to the "Under Discussion"
>>>>> session and get the ball rolling formally. Please enlighten and I'll
>>>>> do whatever is required.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --
>>>>> Tom Boutell
>>>>> P'unk Avenue
>>>>> 215 755 1330
>>>>> punkave.com
>>>>> window.punkave.com
>>>>>
>>>>> --
>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>
>>
>>
>>
>> --
>> Tom Boutell
>> P'unk Avenue
>> 215 755 1330
>> punkave.com
>> window.punkave.com
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kris Craig
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 07:20AM
Tom,

On Sun, Apr 8, 2012 at 4:14 PM, Tom Boutell <[email protected]> wrote:

> Thanks. However, would you please fix the summary on the RFC's page to
> match the summary in the actual RFC? As you have written it, it
> implies that support for <?php would be completely removed. This is
> not the case.
>
> As for adding a boolean parameter to the require keyword, as the RFC
> mentions there are already at least two distinctions already when
> requiring files in PHP:
>
> * include vs. require behavior (warning vs. error on failure)
> * once vs. every time (require_once vs. require)
>
> And we are proposing a third:
>
> * start in php mode vs. start in html mode
>
> We already have four keywords for requiring files. At this point it
> does not make sense to keep introducing more keywords (we would need 8
> with this change). Your boolean flag proposal keeps it to four
> keywords, but as soon as someone adds another flag it will become
> awkward to remember them. Since PHP does not have named parameters I
> think an associative array is the best way to go (especially with the
> new short syntax).
>
> Also I don't think it makes sense to forbid shifting into html mode
> later in the file, it could reduce support for the proposal needlessly
> - since it already lets people who want to write clean all-PHP files
> do so, and some of those people might have legitimate reasons to use
> HTML mode in the scope of a function or method (where it does not
> suddenly introduce whitespace without being explicitly called, etc).
>
> But if it really came down to it I could live with an "absolutely
> nothing but PHP" behavior when the code flag is true (supporting <?php
> when the flag is not set is a must of course).
>
> On Sun, Apr 8, 2012 at 6:45 PM, Yasuo Ohgaki <[email protected]> wrote:
> > Hi,
> >
> > I talked on twitter.
> > Yes, he is kidding, but he is serious, too.
> >
> > I've added the RFC to Under Discussion and added
> > security issue description. I also added my proposal that
> > controls embed mode.
> >
> > BTW, I don't think we need new "require_path" why don't
> > we use
> >
> > require "file.php", ture;
> >
> > or some thing similar?
> > I prefer to use switch, since security countermeasure is
> > better to be enforced by switch.
> >
> > Regards,
> >
> > --
> > Yasuo Ohgaki
> > yohgaki@ohgaki.net
> >
> >
> >
> > 2012/4/9 Tom Boutell <[email protected]>:
> >> Moriyoshi was kidding, as near as I can tell (:
> >>
> >> To take it at face value though, the *cough* April 1st *cough*
> >> proposal of Moriyoshi calls for the complete abolition of the feature
> >> with no backwards compatibility with existing code that uses PHP as a
> >> template language... including most popular frameworks that sensibly
> >> obey a separation between class files and template files but still use
> >> PHP rather than a dedicated templating language for templates.
> >>
> >> I don't think that's realistic (and neither did the author it
> >> appears). Since PHP's usability as a template language may conceivably
> >> be improved by other proposals, it is undesirable as well even if you
> >> don't currently find PHP to be a suitable template language.
> >>
> >> Please read my proposal over carefully as it does address the obvious
> >> issues that make Moriyoshi's proposal possibly less than serious in
> >> intent (:
> >>
> >> I would oppose a php.ini flag for this as that gives us two
> >> incompatible versions of the current version of the language to worry
> >> about and makes the feature effectively unusable in reusable code.
> >> This approach has created problems before.
> >>
> >> On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki <[email protected]>
> wrote:
> >>> Hi,
> >>>
> >>> There is RFC that is written by Moriyoshi.
> >>> It's not listed in RFC page, though.
> >>>
> >>> https://wiki.php.net/rfc/nophptags
> >>>
> >>> I think these should be merged.
> >>>
> >>> Regards,
> >>>
> >>> --
> >>> Yasuo Ohgaki
> >>> yohgaki@ohgaki.net
> >>>
> >>>
> >>>
> >>> 2012/4/9 Yasuo Ohgaki <[email protected]>:
> >>>> Hi,
> >>>>
> >>>> Moriyoshi has created same entry on 4/1, but
> >>>> it seems it was deleted already.
> >>>>
> >>>> Anyway, he had a patch for it.
> >>>>
> >>>> https://gist.github.com/2266652
> >>>>
> >>>> As I mentioned in other thread, we should better to have
> >>>> a switch to disable embed mode for security reasons.
> >>>>
> >>>> Regards,
> >>>>
> >>>> --
> >>>> Yasuo Ohgaki
> >>>> yohgaki@ohgaki.net
> >>>>
> >>>>
> >>>>
> >>>> 2012/4/9 Tom Boutell <[email protected]>:
> >>>>> I have written an RFC proposing backwards-compatible support for
> >>>>> source files without an opening <?php tag:
> >>>>>
> >>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
> >>>>>
> >>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not
> sure
> >>>>> what the requirements are to get it added to the "Under Discussion"
> >>>>> session and get the ball rolling formally. Please enlighten and I'll
> >>>>> do whatever is required.
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> --
> >>>>> Tom Boutell
> >>>>> P'unk Avenue
> >>>>> 215 755 1330
> >>>>> punkave.com
> >>>>> window.punkave.com
> >>>>>
> >>>>> --
> >>>>> PHP Internals - PHP Runtime Development Mailing List
> >>>>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>>>
> >>
> >>
> >>
> >> --
> >> Tom Boutell
> >> P'unk Avenue
> >> 215 755 1330
> >> punkave.com
> >> window.punkave.com
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
>
>
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I think this is a great idea overall, but it seems to me as though we're
needlessly over-complicating things. If we just go with a separate file
extension for pure PHP code (i.e. everything in the file is parsed as if it
was contained in a <?php tag and the ?> tag would throw an error), then
there's no need for adding new keywords or INI flags. If a pure PHP file
includes a regular PHP file that contains HTML, a warning would be thrown
and anything not within the <?php tag of the included file would be
ignored. Everybody's happy. No BC breaks. No additional flags/keywords
to muddle around with.

That said, we might want to consider a file extension other than ".phpc".
There are some PHP-related projects/commits that already use this file
extension for other purposes and could be broken by this. Probably
wouldn't be a huge deal but a quick Google search shows that we would be
stepping on a few people's toes by going with that extension.

Instead, how about going with ".phpp" (as-in, "PHP Pure")? A Google search
on that shows it's not being used anywhere (except for one blog post from
2007 that linked to a .phpp file, but it looks like he just named it that
so that it wouldn't be parsed by the webserver). That way we wouldn't be
creating any conflicts with existing applications/projects. =)

--Kris
Yasuo Ohgaki
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 07:50AM
Hi,

I modified the title.

> * include vs. require behavior (warning vs. error on failure)
> * once vs. every time (require_once vs. require)
>
> And we are proposing a third:

Then, better name would be require_script()/include_script().

However, this option will not solve script inclusion security
issues. Fixing security issues will not have much opposition,
but adding new syntax will.

I like embedded languages, but programmers can write vulnerable
code with it. Embed feature is better to be controlled by programmers/
administrators for better security.

Regards,

P.S. I'm uncomfortable with current PHP, since someone
may write "include $_GET['module']" or like for my systems.
This code raises fatal security issue with current PHP, but
it's not with my proposal.

--
Yasuo Ohgaki
yohgaki@ohgaki.net



2012/4/9 Tom Boutell <[email protected]>:
> Thanks. However, would you please fix the summary on the RFC's page to
> match the summary in the actual RFC? As you have written it, it
> implies that support for <?php would be completely removed. This is
> not the case.
>
> As for adding a boolean parameter to the require keyword, as the RFC
> mentions there are already at least two distinctions already when
> requiring files in PHP:
>
> * include vs. require behavior (warning vs. error on failure)
> * once vs. every time (require_once vs. require)
>
> And we are proposing a third:
>
> * start in php mode vs. start in html mode
>
> We already have four keywords for requiring files. At this point it
> does not make sense to keep introducing more keywords (we would need 8
> with this change). Your boolean flag proposal keeps it to four
> keywords, but as soon as someone adds another flag it will become
> awkward to remember them. Since PHP does not have named parameters I
> think an associative array is the best way to go (especially with the
> new short syntax).
>
> Also I don't think it makes sense to forbid shifting into html mode
> later in the file, it could reduce support for the proposal needlessly
> - since it already lets people who want to write clean all-PHP files
> do so, and some of those people might have legitimate reasons to use
> HTML mode in the scope of a function or method (where it does not
> suddenly introduce whitespace without being explicitly called, etc).
>
> But if it really came down to it I could live with an "absolutely
> nothing but PHP" behavior when the code flag is true (supporting <?php
> when the flag is not set is a must of course).
>
> On Sun, Apr 8, 2012 at 6:45 PM, Yasuo Ohgaki <[email protected]> wrote:
>> Hi,
>>
>> I talked on twitter.
>> Yes, he is kidding, but he is serious, too.
>>
>> I've added the RFC to Under Discussion and added
>> security issue description. I also added my proposal that
>> controls embed mode.
>>
>> BTW, I don't think we need new "require_path" why don't
>> we use
>>
>> require "file.php", ture;
>>
>> or some thing similar?
>> I prefer to use switch, since security countermeasure is
>> better to be enforced by switch.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohgaki@ohgaki.net
>>
>>
>>
>> 2012/4/9 Tom Boutell <[email protected]>:
>>> Moriyoshi was kidding, as near as I can tell (:
>>>
>>> To take it at face value though, the *cough* April 1st *cough*
>>> proposal of Moriyoshi calls for the complete abolition of the feature
>>> with no backwards compatibility with existing code that uses PHP as a
>>> template language... including most popular frameworks that sensibly
>>> obey a separation between class files and template files but still use
>>> PHP rather than a dedicated templating language for templates.
>>>
>>> I don't think that's realistic (and neither did the author it
>>> appears). Since PHP's usability as a template language may conceivably
>>> be improved by other proposals, it is undesirable as well even if you
>>> don't currently find PHP to be a suitable template language.
>>>
>>> Please read my proposal over carefully as it does address the obvious
>>> issues that make Moriyoshi's proposal possibly less than serious in
>>> intent (:
>>>
>>> I would oppose a php.ini flag for this as that gives us two
>>> incompatible versions of the current version of the language to worry
>>> about and makes the feature effectively unusable in reusable code.
>>> This approach has created problems before.
>>>
>>> On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki <[email protected]> wrote:
>>>> Hi,
>>>>
>>>> There is RFC that is written by Moriyoshi.
>>>> It's not listed in RFC page, though.
>>>>
>>>> https://wiki.php.net/rfc/nophptags
>>>>
>>>> I think these should be merged.
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> Yasuo Ohgaki
>>>> yohgaki@ohgaki.net
>>>>
>>>>
>>>>
>>>> 2012/4/9 Yasuo Ohgaki <[email protected]>:
>>>>> Hi,
>>>>>
>>>>> Moriyoshi has created same entry on 4/1, but
>>>>> it seems it was deleted  already.
>>>>>
>>>>> Anyway, he had a patch for it.
>>>>>
>>>>> https://gist.github.com/2266652
>>>>>
>>>>> As I mentioned in other thread, we should better to have
>>>>> a switch to disable embed mode for security reasons.
>>>>>
>>>>> Regards,
>>>>>
>>>>> --
>>>>> Yasuo Ohgaki
>>>>> yohgaki@ohgaki.net
>>>>>
>>>>>
>>>>>
>>>>> 2012/4/9 Tom Boutell <[email protected]>:
>>>>>> I have written an RFC proposing backwards-compatible support for
>>>>>> source files without an opening <?php tag:
>>>>>>
>>>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>>>>
>>>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>>>>>> what the requirements are to get it added to the "Under Discussion"
>>>>>> session and get the ball rolling formally. Please enlighten and I'll
>>>>>> do whatever is required.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> --
>>>>>> Tom Boutell
>>>>>> P'unk Avenue
>>>>>> 215 755 1330
>>>>>> punkave.com
>>>>>> window.punkave.com
>>>>>>
>>>>>> --
>>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>>
>>>
>>>
>>>
>>> --
>>> Tom Boutell
>>> P'unk Avenue
>>> 215 755 1330
>>> punkave.com
>>> window.punkave.com
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>
>
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> 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
Yasuo Ohgaki
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 08:20AM
Hi Tom,

It's better to distinguish security related issue and others.
Therefore, I listed Moriyoshi's proposal to RFC list and put
my proposal in it. His proposal is almost the same as mine
except the flag for embed mode control.

https://wiki.php.net/rfc/nophptags

I recovered the original except for adding references to No
PHP Tags RFC.

https://wiki.php.net/rfc/source_files_without_opening_tag

This makes discussion more clear to everyone, I hope.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tom Boutell
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 01:00PM
..phpp would be fine.

..phpp code needs to be able to interoperate with .php templates, otherwise one can't supply reusable libraries that implement generic algorithms without surprises for those who integrate them in older projects.

Sent from my iPhone

On Apr 9, 2012, at 1:16 AM, Kris Craig <[email protected]> wrote:

> Tom,
>
> On Sun, Apr 8, 2012 at 4:14 PM, Tom Boutell <[email protected]> wrote:
> Thanks. However, would you please fix the summary on the RFC's page to
> match the summary in the actual RFC? As you have written it, it
> implies that support for <?php would be completely removed. This is
> not the case.
>
> As for adding a boolean parameter to the require keyword, as the RFC
> mentions there are already at least two distinctions already when
> requiring files in PHP:
>
> * include vs. require behavior (warning vs. error on failure)
> * once vs. every time (require_once vs. require)
>
> And we are proposing a third:
>
> * start in php mode vs. start in html mode
>
> We already have four keywords for requiring files. At this point it
> does not make sense to keep introducing more keywords (we would need 8
> with this change). Your boolean flag proposal keeps it to four
> keywords, but as soon as someone adds another flag it will become
> awkward to remember them. Since PHP does not have named parameters I
> think an associative array is the best way to go (especially with the
> new short syntax).
>
> Also I don't think it makes sense to forbid shifting into html mode
> later in the file, it could reduce support for the proposal needlessly
> - since it already lets people who want to write clean all-PHP files
> do so, and some of those people might have legitimate reasons to use
> HTML mode in the scope of a function or method (where it does not
> suddenly introduce whitespace without being explicitly called, etc).
>
> But if it really came down to it I could live with an "absolutely
> nothing but PHP" behavior when the code flag is true (supporting <?php
> when the flag is not set is a must of course).
>
> On Sun, Apr 8, 2012 at 6:45 PM, Yasuo Ohgaki <[email protected]> wrote:
> > Hi,
> >
> > I talked on twitter.
> > Yes, he is kidding, but he is serious, too.
> >
> > I've added the RFC to Under Discussion and added
> > security issue description. I also added my proposal that
> > controls embed mode.
> >
> > BTW, I don't think we need new "require_path" why don't
> > we use
> >
> > require "file.php", ture;
> >
> > or some thing similar?
> > I prefer to use switch, since security countermeasure is
> > better to be enforced by switch.
> >
> > Regards,
> >
> > --
> > Yasuo Ohgaki
> > yohgaki@ohgaki.net
> >
> >
> >
> > 2012/4/9 Tom Boutell <[email protected]>:
> >> Moriyoshi was kidding, as near as I can tell (:
> >>
> >> To take it at face value though, the *cough* April 1st *cough*
> >> proposal of Moriyoshi calls for the complete abolition of the feature
> >> with no backwards compatibility with existing code that uses PHP as a
> >> template language... including most popular frameworks that sensibly
> >> obey a separation between class files and template files but still use
> >> PHP rather than a dedicated templating language for templates.
> >>
> >> I don't think that's realistic (and neither did the author it
> >> appears). Since PHP's usability as a template language may conceivably
> >> be improved by other proposals, it is undesirable as well even if you
> >> don't currently find PHP to be a suitable template language.
> >>
> >> Please read my proposal over carefully as it does address the obvious
> >> issues that make Moriyoshi's proposal possibly less than serious in
> >> intent (:
> >>
> >> I would oppose a php.ini flag for this as that gives us two
> >> incompatible versions of the current version of the language to worry
> >> about and makes the feature effectively unusable in reusable code.
> >> This approach has created problems before.
> >>
> >> On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki <[email protected]> wrote:
> >>> Hi,
> >>>
> >>> There is RFC that is written by Moriyoshi.
> >>> It's not listed in RFC page, though.
> >>>
> >>> https://wiki.php.net/rfc/nophptags
> >>>
> >>> I think these should be merged.
> >>>
> >>> Regards,
> >>>
> >>> --
> >>> Yasuo Ohgaki
> >>> yohgaki@ohgaki.net
> >>>
> >>>
> >>>
> >>> 2012/4/9 Yasuo Ohgaki <[email protected]>:
> >>>> Hi,
> >>>>
> >>>> Moriyoshi has created same entry on 4/1, but
> >>>> it seems it was deleted already.
> >>>>
> >>>> Anyway, he had a patch for it.
> >>>>
> >>>> https://gist.github.com/2266652
> >>>>
> >>>> As I mentioned in other thread, we should better to have
> >>>> a switch to disable embed mode for security reasons.
> >>>>
> >>>> Regards,
> >>>>
> >>>> --
> >>>> Yasuo Ohgaki
> >>>> yohgaki@ohgaki.net
> >>>>
> >>>>
> >>>>
> >>>> 2012/4/9 Tom Boutell <[email protected]>:
> >>>>> I have written an RFC proposing backwards-compatible support for
> >>>>> source files without an opening <?php tag:
> >>>>>
> >>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
> >>>>>
> >>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
> >>>>> what the requirements are to get it added to the "Under Discussion"
> >>>>> session and get the ball rolling formally. Please enlighten and I'll
> >>>>> do whatever is required.
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> --
> >>>>> Tom Boutell
> >>>>> P'unk Avenue
> >>>>> 215 755 1330
> >>>>> punkave.com
> >>>>> window.punkave.com
> >>>>>
> >>>>> --
> >>>>> PHP Internals - PHP Runtime Development Mailing List
> >>>>> To unsubscribe, visit: http://www.php.net/unsub.php
> >>>>>
> >>
> >>
> >>
> >> --
> >> Tom Boutell
> >> P'unk Avenue
> >> 215 755 1330
> >> punkave.com
> >> window.punkave.com
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
>
>
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> I think this is a great idea overall, but it seems to me as though we're needlessly over-complicating things. If we just go with a separate file extension for pure PHP code (i.e. everything in the file is parsed as if it was contained in a <?php tag and the ?> tag would throw an error), then there's no need for adding new keywords or INI flags. If a pure PHP file includes a regular PHP file that contains HTML, a warning would be thrown and anything not within the <?php tag of the included file would be ignored. Everybody's happy. No BC breaks. No additional flags/keywords to muddle around with.
>
> That said, we might want to consider a file extension other than ".phpc". There are some PHP-related projects/commits that already use this file extension for other purposes and could be broken by this. Probably wouldn't be a huge deal but a quick Google search shows that we would be stepping on a few people's toes by going with that extension.
>
> Instead, how about going with ".phpp" (as-in, "PHP Pure")? A Google search on that shows it's not being used anywhere (except for one blog post from 2007 that linked to a .phpp file, but it looks like he just named it that so that it wouldn't be parsed by the webserver). That way we wouldn't be creating any conflicts with existing applications/projects. =)
>
> --Kris
>
Tom Boutell
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 01:00PM
I think separating these rfcs makes sense, thanks.

Sent from my iPhone

On Apr 9, 2012, at 2:17 AM, Yasuo Ohgaki <[email protected]> wrote:

> Hi Tom,
>
> It's better to distinguish security related issue and others.
> Therefore, I listed Moriyoshi's proposal to RFC list and put
> my proposal in it. His proposal is almost the same as mine
> except the flag for embed mode control.
>
> https://wiki.php.net/rfc/nophptags
>
> I recovered the original except for adding references to No
> PHP Tags RFC.
>
> https://wiki.php.net/rfc/source_files_without_opening_tag
>
> This makes discussion more clear to everyone, I hope.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tom Boutell
[PHP-DEV] Re: RFC: source files without opening tag
April 09, 2012 01:30PM
I would like to clarify what this RFC actually says. Let's try to keep
this thread to the pros and cons of this specific proposal.

The following new keyword would be introduced:

require_path

This keyword has two parameters of which the second is optional. The
first parameter is the path (filename or URL) to be required, and
behaves exactly as the sole parameter of the require keyword behaves.
The second parameter is an associative array.

If this second parameter is absent, require_path behaves exactly like require.

If the second parameter is present, the following keys may optionally
be present in the array, with the following effects:

If 'once' is present and true, the specified path is loaded no more
than once, exactly like require_once.

If 'warn' is present and true, a loading or compilation error results
in E_WARNING (per the current behavior of the include keyword). If
warn is absent or false, a loading or compilation error results in
E_COMPILE_ERROR (per the current behavior of the require keyword).

If 'code' is present and true, the parser begins reading the file as
if a <?php open tag had already been encountered. If code is absent or
false, the parser reads the file beginning in “HTML mode,” exactly as
the require keyword does today.

Examples:

// Behaves just like require
require_path 'filename.php';

// Behaves just like include_once
require_path 'filename.php', array('warn' => true, 'once' => true);

// Loads a file starting out in "PHP mode" so the opening <?php is not required
require_path 'filename.php', array('code' => true);

In addition, a convention (not a requirement checked by the code)
would be encouraged: PHP source code files without an initial <?php
would be named with a .phpc file extension.

That's all the RFC calls for. The rest of it is just responses to
frequently raised concerns:

https://wiki.php.net/rfc/source_files_without_opening_tag

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ángel González
Re: [PHP-DEV] Re: RFC: source files without opening tag
April 09, 2012 02:30PM
On 09/04/12 13:29, Tom Boutell wrote:
> I would like to clarify what this RFC actually says. Let's try to keep
> this thread to the pros and cons of this specific proposal.
>
> The following new keyword would be introduced:
>
> require_path
I don't like the keyword name. Too confusing with the include_path
configuration option for something very different.

What about require_file ?


> This keyword has two parameters of which the second is optional. The
> first parameter is the path (filename or URL) to be required, and
> behaves exactly as the sole parameter of the require keyword behaves.
> The second parameter is an associative array.
Does it require brackets?



> If 'warn' is present and true, a loading or compilation error results
> in E_WARNING (per the current behavior of the include keyword). If
> warn is absent or false, a loading or compilation error results in
> E_COMPILE_ERROR (per the current behavior of the require keyword).
What if I want to silently ignore a missing-file condition?
Ie. no warning or compile error if there file is not there (presumably
to skip the need of a file_exist), yet receive all warnings generated by
the included code.

What about 'missing'=> 'error' / 'warn' / 'ignore' ?


> If 'code' is present and true, the parser begins reading the file as
> if a <?php open tag had already been encountered. If code is absent or
> false, the parser reads the file beginning in “HTML mode,” exactly as
> the require keyword does today.
I think "reading the file as if a <?php open tag had already been
encountered" should add
"with the exception that an explicit <?php exactly at the beginning of
the file is not a parse error but silently ignored".


Best regards


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rick WIdmer
Re: [PHP-DEV] Re: RFC: source files without opening tag
April 09, 2012 03:20PM
Option 1: Introduce require_path

I think require_code is a better name. Parm 1 isn't a path, it is a
file, so require_path seems wrong to me.

I'd prefer a 'start in code mode' optional second parameter to
include[_once] and require[_once].


Option 2: Filename Convention

The PHP engine should not know or care what the file extension is. I
won't object if you can convince autoloader authors to follow the .phpc
convention. Personally, once I can count on this feature, every file I
include/require will probably be written starting in code mode and using
the new calling convention. Even when I use PHP to create page templates...


Additional suggestions:

Add an option so the CLI can start in code mode too.

Add another Handler to the Apache SAPI, maybe
application/x-httpd-php-code similar to x-httpd-php and
x-httpd-php-source, so we can configure Apache to start arbitrary file
extensions with code mode on. This defers setting the action for
various file extensions to the person configuring the web server.

Other web server SAPIs will need similar treatment, but I'll leave them
to someone with personal experience.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tom Boutell
Re: [PHP-DEV] Re: RFC: source files without opening tag
April 09, 2012 03:50PM
On Mon, Apr 9, 2012 at 9:16 AM, Rick WIdmer <[email protected]> wrote:
>
> Option 1: Introduce require_path
>
> I think require_code is a better name.  Parm 1 isn't a path, it is a file,
> so require_path seems wrong to me.

Yeah, you're not the first to say this. require_file and require_code
have both been suggested. I'm fine with either really.

> I'd prefer a 'start in code mode' optional second parameter to
> include[_once] and require[_once].

That would be fine as far as my goals here go, but I'm concerned that
we'll just repeat this discussion if any other options for requiring
things come into being (:

> Option 2: Filename Convention
>
> The PHP engine should not know or care what the file extension is.  I won't
> object if you can convince autoloader authors to follow the .phpc
> convention.  Personally, once I can count on this feature, every file I
> include/require will probably be written starting in code mode and using the
> new calling convention.  Even when I use PHP to create page templates....

Sounds like you're basically OK with that bit.

> Additional suggestions:
>
> Add an option so the CLI can start in code mode too.
>
> Add another Handler to the Apache SAPI, maybe application/x-httpd-php-code
> similar to x-httpd-php and x-httpd-php-source, so we can configure Apache to
> start arbitrary file extensions with code mode on.  This defers setting the
> action for various file extensions to the person configuring the web server.
>
> Other web server SAPIs will need similar treatment, but I'll leave them to
> someone with personal experience.

I'm not opposed to these suggestions. I was trying to keep it
conservative and simple to implement and focus on the case where it
bugs me (creating libraries of class files), but I'd be happy to see a
way for .phpc to be the entry point / frontend controller / standalone
script as well. As you say it must be done with SAPI options (the CLI
included), not hardcoded file extension checking.

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
IDE creators will definitely be excited with this new feature.

2012/4/9 Tom Boutell <[email protected]>

> On Mon, Apr 9, 2012 at 9:16 AM, Rick WIdmer <[email protected]>
> wrote:
> >
> > Option 1: Introduce require_path
> >
> > I think require_code is a better name. Parm 1 isn't a path, it is a
> file,
> > so require_path seems wrong to me.
>
> Yeah, you're not the first to say this. require_file and require_code
> have both been suggested. I'm fine with either really.
>
> > I'd prefer a 'start in code mode' optional second parameter to
> > include[_once] and require[_once].
>
> That would be fine as far as my goals here go, but I'm concerned that
> we'll just repeat this discussion if any other options for requiring
> things come into being (:
>
> > Option 2: Filename Convention
> >
> > The PHP engine should not know or care what the file extension is. I
> won't
> > object if you can convince autoloader authors to follow the .phpc
> > convention. Personally, once I can count on this feature, every file I
> > include/require will probably be written starting in code mode and using
> the
> > new calling convention. Even when I use PHP to create page templates...
>
> Sounds like you're basically OK with that bit.
>
> > Additional suggestions:
> >
> > Add an option so the CLI can start in code mode too.
> >
> > Add another Handler to the Apache SAPI, maybe
> application/x-httpd-php-code
> > similar to x-httpd-php and x-httpd-php-source, so we can configure
> Apache to
> > start arbitrary file extensions with code mode on. This defers setting
> the
> > action for various file extensions to the person configuring the web
> server.
> >
> > Other web server SAPIs will need similar treatment, but I'll leave them
> to
> > someone with personal experience.
>
> I'm not opposed to these suggestions. I was trying to keep it
> conservative and simple to implement and focus on the case where it
> bugs me (creating libraries of class files), but I'd be happy to see a
> way for .phpc to be the entry point / frontend controller / standalone
> script as well. As you say it must be done with SAPI options (the CLI
> included), not hardcoded file extension checking.
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Luke Scott
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 05:50PM
Tom,

As I've said before I don't think new keywords are the answer. They
will just pollute the language even further.

I also don't think an ini setting is a bad thing either. It is often
used in PHP as a way to transition from way of doing things to
another. First you introduce it with it being off by default, then on
by default, then deprecate the old behavior. It's quite normal in
PHP's history.

In another email someone mentioned doing two rfcs. In both cases are
we talking about removing <?php ? Because it's become somewhat
confusing to keep track of what is being talked about. If that is the
case, continue reading.

I would prefer the starting <?php tag be optional rather than removed.
Just explicitly forbid the ending ?> tag and treat text before the
opening <?php tag differently. Perhaps ignore it (rather than print)
or throw an error.

That is at least how I would prefer the "code" mode as most
non-template files only start with <?php. It allows for backwards
compatibility.

If you must add keywords it should be something like require_template
NOT require_code/require_file. Templates are the exception, not the
norm.

Luke Scott

On Apr 8, 2012, at 9:32 AM, Tom Boutell <[email protected]> wrote:

> I have written an RFC proposing backwards-compatible support for
> source files without an opening <?php tag:
>
> https://wiki.php.net/rfc/source_files_without_opening_tag
>
> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
> what the requirements are to get it added to the "Under Discussion"
> session and get the ball rolling formally. Please enlighten and I'll
> do whatever is required.
>
> Thanks!
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> 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
Tom Boutell
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 06:20PM
It sounds like you are proposing to gradually kill the use of PHP for
templating entirely, which I don't think is something people would
vote for. I sometimes use perfectly good older frameworks that do use
..php files for templating in a reasonable way, and I'm one of the
advocates for migrating away from starting everything with <?php. I
would have to vote against it myself. There's no reason to kill good
code that passes its tests just because it uses inline HTML. I won't
even know I have that code in my project from some third party library
until I find out the hard way. No, just no. (:

I did propose one new keyword, but by proposing one keyword with a
future-friendly syntax instead of four new keywords I'm attempting to
help with the pollution problem.

On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott <[email protected]> wrote:
> Tom,
>
> As I've said before I don't think new keywords are the answer. They
> will just pollute the language even further.
>
> I also don't think an ini setting is a bad thing either. It is often
> used in PHP as a way to transition from way of doing things to
> another. First you introduce it with it being off by default, then on
> by default, then deprecate the old behavior. It's quite normal in
> PHP's history.
>
> In another email someone mentioned doing two rfcs. In both cases are
> we talking about removing <?php ? Because it's become somewhat
> confusing to keep track of what is being talked about. If that is the
> case, continue reading.
>
> I would prefer the starting <?php tag be optional rather than removed.
> Just explicitly forbid the ending ?> tag and treat text before the
> opening <?php tag differently. Perhaps ignore it (rather than print)
> or throw an error.
>
> That is at least how I would prefer the "code" mode as most
> non-template files only start with <?php. It allows for backwards
> compatibility.
>
> If you must add keywords it should be something like require_template
> NOT require_code/require_file. Templates are the exception, not the
> norm.
>
> Luke Scott
>
> On Apr 8, 2012, at 9:32 AM, Tom Boutell <[email protected]> wrote:
>
>> I have written an RFC proposing backwards-compatible support for
>> source files without an opening <?php tag:
>>
>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>
>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>> what the requirements are to get it added to the "Under Discussion"
>> session and get the ball rolling formally. Please enlighten and I'll
>> do whatever is required.
>>
>> Thanks!
>>
>> --
>> Tom Boutell
>> P'unk Avenue
>> 215 755 1330
>> punkave.com
>> window.punkave.com
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Luke Scott
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 07:20PM
On Apr 9, 2012, at 9:16 AM, Tom Boutell <[email protected]> wrote:

> It sounds like you are proposing to gradually kill the use of PHP for
> templating entirely, which I don't think is something people would
> vote for.

I'm not saying that at all. I'm saying that PHP code should be clearly
separated from template code. <?php should be optional at the start of
the file and IF a keyword should be added it should be for templates
and short-tags.

99% of modern PHP code is going to be classes that start with <?php
and omit the ending ?> (since PHP 5 due to how easy it is for white
space to end up on the tail end of a file). this is even the case with
procedural code.

Half the PHP frameworks out there have their own template engine
because they can do a lot more than what short tags offer. Example:
Twig offers template inheritance.

Introducing a keyword for PHP code without the <?php tag is
impractical. It makes much more sense to have a keyword for templates.

For non-template code the starting <?php tag should always work as it
has before for backwards compatibility. The difference is you cannot
use ?> and text before the opening <?php tag is either ignored or
throws an error.

> I sometimes use perfectly good older frameworks that do use
> .php files for templating in a reasonable way, and I'm one of the
> advocates for migrating away from starting everything with <?php. I
> would have to vote against it myself.

And those files can be included with something like require_template
or you can turn off the option in the ini file.

The point is in EITHER MODE a php file that starts with <?php will
work as it did before. The new mode would just disallow you to break
out of PHP code with ?>.

> There's no reason to kill good
> code that passes its tests just because it uses inline HTML. I won't
> even know I have that code in my project from some third party library
> until I find out the hard way. No, just no. (:

I'm not trying to kill anything. In fact what I'm proposing would be a
smooth transition to something that is already done. The difference is
at some point you won't be able to do this:

<?php
class Object
{
public function output()
{
?>
Print me!
<?php
}
}

I cringe every time I see this. There is no excuse since we have here/nowdocs.

For people that use PHP as a template there can be other options. I'm
not totally against a new keyword, but I am against a new keyword for
including normal PHP code. It just doesn't make sense. No matter what
you name it (require_code, require_file, require_path) it's damned
confusing. If you did it the other way around its much clearer:
require_template.

With require_template you're also free to expand template
functionality while keeping code clearly separated.

> I did propose one new keyword, but by proposing one keyword with a
> future-friendly syntax instead of four new keywords I'm attempting to
> help with the pollution problem.

It's not as much as adding a keyword as it is what keyword you're adding.

I hope the way I've explained things makes sense.

Luke

>
> On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott <[email protected]> wrote:
>> Tom,
>>
>> As I've said before I don't think new keywords are the answer. They
>> will just pollute the language even further.
>>
>> I also don't think an ini setting is a bad thing either. It is often
>> used in PHP as a way to transition from way of doing things to
>> another. First you introduce it with it being off by default, then on
>> by default, then deprecate the old behavior. It's quite normal in
>> PHP's history.
>>
>> In another email someone mentioned doing two rfcs. In both cases are
>> we talking about removing <?php ? Because it's become somewhat
>> confusing to keep track of what is being talked about. If that is the
>> case, continue reading.
>>
>> I would prefer the starting <?php tag be optional rather than removed.
>> Just explicitly forbid the ending ?> tag and treat text before the
>> opening <?php tag differently. Perhaps ignore it (rather than print)
>> or throw an error.
>>
>> That is at least how I would prefer the "code" mode as most
>> non-template files only start with <?php. It allows for backwards
>> compatibility.
>>
>> If you must add keywords it should be something like require_template
>> NOT require_code/require_file. Templates are the exception, not the
>> norm.
>>
>> Luke Scott
>>
>> On Apr 8, 2012, at 9:32 AM, Tom Boutell <[email protected]> wrote:
>>
>>> I have written an RFC proposing backwards-compatible support for
>>> source files without an opening <?php tag:
>>>
>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>
>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>>> what the requirements are to get it added to the "Under Discussion"
>>> session and get the ball rolling formally. Please enlighten and I'll
>>> do whatever is required.
>>>
>>> Thanks!
>>>
>>> --
>>> Tom Boutell
>>> P'unk Avenue
>>> 215 755 1330
>>> punkave.com
>>> window.punkave.com
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>
>
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> 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
Tom Boutell
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 07:30PM
I see what you're saying, but you're proposing a new keyword to
include code that does what plain old 'require' does now (assuming
it's not a nice clean class file that is being included). Which means
that valid code today is busted code once this feature comes out. That
seems like a very hard sell.

On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott <[email protected]> wrote:
> On Apr 9, 2012, at 9:16 AM, Tom Boutell <[email protected]> wrote:
>
>> It sounds like you are proposing to gradually kill the use of PHP for
>> templating entirely, which I don't think is something people would
>> vote for.
>
> I'm not saying that at all. I'm saying that PHP code should be clearly
> separated from template code. <?php should be optional at the start of
> the file and IF a keyword should be added it should be for templates
> and short-tags.
>
> 99% of modern PHP code is going to be classes that start with <?php
> and omit the ending ?> (since PHP 5 due to how easy it is for white
> space to end up on the tail end of a file). this is even the case with
> procedural code.
>
> Half the PHP frameworks out there have their own template engine
> because they can do a lot more than what short tags offer. Example:
> Twig offers template inheritance.
>
> Introducing a keyword for PHP code without the <?php tag is
> impractical. It makes much more sense to have a keyword for templates.
>
> For non-template code the starting <?php tag should always work as it
> has before for backwards compatibility. The difference is you cannot
> use ?> and text before the opening <?php tag is either ignored or
> throws an error.
>
>> I sometimes use perfectly good older frameworks that do use
>> .php files for templating in a reasonable way, and I'm one of the
>> advocates for migrating away from starting everything with <?php. I
>> would have to vote against it myself.
>
> And those files can be included with something like require_template
> or you can turn off the option in the ini file.
>
> The point is in EITHER MODE a php file that starts with <?php will
> work as it did before. The new mode would just disallow you to break
> out of PHP code with ?>.
>
>> There's no reason to kill good
>> code that passes its tests just because it uses inline HTML. I won't
>> even know I have that code in my project from some third party library
>> until I find out the hard way. No, just no. (:
>
> I'm not trying to kill anything. In fact what I'm proposing would be a
> smooth transition to something that is already done. The difference is
> at some point you won't be able to do this:
>
> <?php
> class Object
> {
>    public function output()
>    {
> ?>
> Print me!
> <?php
>    }
> }
>
> I cringe every time I see this. There is no excuse since we have here/nowdocs.
>
> For people that use PHP as a template there can be other options. I'm
> not totally against a new keyword, but I am against a new keyword for
> including normal PHP code. It just doesn't make sense. No matter what
> you name it (require_code, require_file, require_path) it's damned
> confusing. If you did it the other way around its much clearer:
> require_template.
>
> With require_template you're also free to expand template
> functionality while keeping code clearly separated.
>
>> I did propose one new keyword, but by proposing one keyword with a
>> future-friendly syntax instead of four new keywords I'm attempting to
>> help with the pollution problem.
>
> It's not as much as adding a keyword as it is what keyword you're adding.
>
> I hope the way I've explained things makes sense.
>
> Luke
>
>>
>> On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott <[email protected]> wrote:
>>> Tom,
>>>
>>> As I've said before I don't think new keywords are the answer. They
>>> will just pollute the language even further.
>>>
>>> I also don't think an ini setting is a bad thing either. It is often
>>> used in PHP as a way to transition from way of doing things to
>>> another. First you introduce it with it being off by default, then on
>>> by default, then deprecate the old behavior. It's quite normal in
>>> PHP's history.
>>>
>>> In another email someone mentioned doing two rfcs. In both cases are
>>> we talking about removing <?php ? Because it's become somewhat
>>> confusing to keep track of what is being talked about. If that is the
>>> case, continue reading.
>>>
>>> I would prefer the starting <?php tag be optional rather than removed.
>>> Just explicitly forbid the ending ?> tag and treat text before the
>>> opening <?php tag differently. Perhaps ignore it (rather than print)
>>> or throw an error.
>>>
>>> That is at least how I would prefer the "code" mode as most
>>> non-template files only start with <?php. It allows for backwards
>>> compatibility.
>>>
>>> If you must add keywords it should be something like require_template
>>> NOT require_code/require_file. Templates are the exception, not the
>>> norm.
>>>
>>> Luke Scott
>>>
>>> On Apr 8, 2012, at 9:32 AM, Tom Boutell <[email protected]> wrote:
>>>
>>>> I have written an RFC proposing backwards-compatible support for
>>>> source files without an opening <?php tag:
>>>>
>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>>
>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>>>> what the requirements are to get it added to the "Under Discussion"
>>>> session and get the ball rolling formally. Please enlighten and I'll
>>>> do whatever is required.
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> Tom Boutell
>>>> P'unk Avenue
>>>> 215 755 1330
>>>> punkave.com
>>>> window.punkave.com
>>>>
>>>> --
>>>> PHP Internals - PHP Runtime Development Mailing List
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>
>>
>>
>> --
>> Tom Boutell
>> P'unk Avenue
>> 215 755 1330
>> punkave.com
>> window.punkave.com
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tom Boutell
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 07:30PM
Also, your objection - that 'require_code' is confusing - would most
likely be an issue for a handful of people who write autoloaders.
Those clean PHP class files are almost always autoloaded.

On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell <[email protected]> wrote:
> I see what you're saying, but you're proposing a new keyword to
> include code that does what plain old 'require' does now (assuming
> it's not a nice clean class file that is being included). Which means
> that valid code today is busted code once this feature comes out. That
> seems like a very hard sell.
>
> On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott <[email protected]> wrote:
>> On Apr 9, 2012, at 9:16 AM, Tom Boutell <[email protected]> wrote:
>>
>>> It sounds like you are proposing to gradually kill the use of PHP for
>>> templating entirely, which I don't think is something people would
>>> vote for.
>>
>> I'm not saying that at all. I'm saying that PHP code should be clearly
>> separated from template code. <?php should be optional at the start of
>> the file and IF a keyword should be added it should be for templates
>> and short-tags.
>>
>> 99% of modern PHP code is going to be classes that start with <?php
>> and omit the ending ?> (since PHP 5 due to how easy it is for white
>> space to end up on the tail end of a file). this is even the case with
>> procedural code.
>>
>> Half the PHP frameworks out there have their own template engine
>> because they can do a lot more than what short tags offer. Example:
>> Twig offers template inheritance.
>>
>> Introducing a keyword for PHP code without the <?php tag is
>> impractical. It makes much more sense to have a keyword for templates.
>>
>> For non-template code the starting <?php tag should always work as it
>> has before for backwards compatibility. The difference is you cannot
>> use ?> and text before the opening <?php tag is either ignored or
>> throws an error.
>>
>>> I sometimes use perfectly good older frameworks that do use
>>> .php files for templating in a reasonable way, and I'm one of the
>>> advocates for migrating away from starting everything with <?php. I
>>> would have to vote against it myself.
>>
>> And those files can be included with something like require_template
>> or you can turn off the option in the ini file.
>>
>> The point is in EITHER MODE a php file that starts with <?php will
>> work as it did before. The new mode would just disallow you to break
>> out of PHP code with ?>.
>>
>>> There's no reason to kill good
>>> code that passes its tests just because it uses inline HTML. I won't
>>> even know I have that code in my project from some third party library
>>> until I find out the hard way. No, just no. (:
>>
>> I'm not trying to kill anything. In fact what I'm proposing would be a
>> smooth transition to something that is already done. The difference is
>> at some point you won't be able to do this:
>>
>> <?php
>> class Object
>> {
>>    public function output()
>>    {
>> ?>
>> Print me!
>> <?php
>>    }
>> }
>>
>> I cringe every time I see this. There is no excuse since we have here/nowdocs.
>>
>> For people that use PHP as a template there can be other options. I'm
>> not totally against a new keyword, but I am against a new keyword for
>> including normal PHP code. It just doesn't make sense. No matter what
>> you name it (require_code, require_file, require_path) it's damned
>> confusing. If you did it the other way around its much clearer:
>> require_template.
>>
>> With require_template you're also free to expand template
>> functionality while keeping code clearly separated.
>>
>>> I did propose one new keyword, but by proposing one keyword with a
>>> future-friendly syntax instead of four new keywords I'm attempting to
>>> help with the pollution problem.
>>
>> It's not as much as adding a keyword as it is what keyword you're adding..
>>
>> I hope the way I've explained things makes sense.
>>
>> Luke
>>
>>>
>>> On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott <[email protected]> wrote:
>>>> Tom,
>>>>
>>>> As I've said before I don't think new keywords are the answer. They
>>>> will just pollute the language even further.
>>>>
>>>> I also don't think an ini setting is a bad thing either. It is often
>>>> used in PHP as a way to transition from way of doing things to
>>>> another. First you introduce it with it being off by default, then on
>>>> by default, then deprecate the old behavior. It's quite normal in
>>>> PHP's history.
>>>>
>>>> In another email someone mentioned doing two rfcs. In both cases are
>>>> we talking about removing <?php ? Because it's become somewhat
>>>> confusing to keep track of what is being talked about. If that is the
>>>> case, continue reading.
>>>>
>>>> I would prefer the starting <?php tag be optional rather than removed.
>>>> Just explicitly forbid the ending ?> tag and treat text before the
>>>> opening <?php tag differently. Perhaps ignore it (rather than print)
>>>> or throw an error.
>>>>
>>>> That is at least how I would prefer the "code" mode as most
>>>> non-template files only start with <?php. It allows for backwards
>>>> compatibility.
>>>>
>>>> If you must add keywords it should be something like require_template
>>>> NOT require_code/require_file. Templates are the exception, not the
>>>> norm.
>>>>
>>>> Luke Scott
>>>>
>>>> On Apr 8, 2012, at 9:32 AM, Tom Boutell <[email protected]> wrote:
>>>>
>>>>> I have written an RFC proposing backwards-compatible support for
>>>>> source files without an opening <?php tag:
>>>>>
>>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>>>
>>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>>>>> what the requirements are to get it added to the "Under Discussion"
>>>>> session and get the ball rolling formally. Please enlighten and I'll
>>>>> do whatever is required.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --
>>>>> Tom Boutell
>>>>> P'unk Avenue
>>>>> 215 755 1330
>>>>> punkave.com
>>>>> window.punkave.com
>>>>>
>>>>> --
>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>
>>>
>>>
>>>
>>> --
>>> Tom Boutell
>>> P'unk Avenue
>>> 215 755 1330
>>> punkave.com
>>> window.punkave.com
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>
>
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Luke Scott
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 07:40PM
On Apr 9, 2012, at 10:23 AM, Tom Boutell <[email protected]> wrote:

> Also, your objection - that 'require_code' is confusing - would most
> likely be an issue for a handful of people who write autoloaders.
> Those clean PHP class files are almost always autoloaded.

Not really. Has nothing to do with auto loaders.

require_code - A literal string? Is this eval?

require_path - A directory?

require_file - What kind of file?

You have to look at the keywords you're proposing and try to explain
then without prior knowledge or documentation.

These keywords are also ambiguous. require/include are well understood
for including code not templates. Not just for PHP.

require_template on the other hand is clear and to the point. It's
hard to make the same kind of assumptions as you can with the other
keywords. And with those who know PHP it's readily apparent
require_template could mean short tags whereas the other leave you
scratching your head.

Luke


>
> On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell <[email protected]> wrote:
>> I see what you're saying, but you're proposing a new keyword to
>> include code that does what plain old 'require' does now (assuming
>> it's not a nice clean class file that is being included). Which means
>> that valid code today is busted code once this feature comes out. That
>> seems like a very hard sell.
>>
>> On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott <[email protected]> wrote:
>>> On Apr 9, 2012, at 9:16 AM, Tom Boutell <[email protected]> wrote:
>>>
>>>> It sounds like you are proposing to gradually kill the use of PHP for
>>>> templating entirely, which I don't think is something people would
>>>> vote for.
>>>
>>> I'm not saying that at all. I'm saying that PHP code should be clearly
>>> separated from template code. <?php should be optional at the start of
>>> the file and IF a keyword should be added it should be for templates
>>> and short-tags.
>>>
>>> 99% of modern PHP code is going to be classes that start with <?php
>>> and omit the ending ?> (since PHP 5 due to how easy it is for white
>>> space to end up on the tail end of a file). this is even the case with
>>> procedural code.
>>>
>>> Half the PHP frameworks out there have their own template engine
>>> because they can do a lot more than what short tags offer. Example:
>>> Twig offers template inheritance.
>>>
>>> Introducing a keyword for PHP code without the <?php tag is
>>> impractical. It makes much more sense to have a keyword for templates.
>>>
>>> For non-template code the starting <?php tag should always work as it
>>> has before for backwards compatibility. The difference is you cannot
>>> use ?> and text before the opening <?php tag is either ignored or
>>> throws an error.
>>>
>>>> I sometimes use perfectly good older frameworks that do use
>>>> .php files for templating in a reasonable way, and I'm one of the
>>>> advocates for migrating away from starting everything with <?php. I
>>>> would have to vote against it myself.
>>>
>>> And those files can be included with something like require_template
>>> or you can turn off the option in the ini file.
>>>
>>> The point is in EITHER MODE a php file that starts with <?php will
>>> work as it did before. The new mode would just disallow you to break
>>> out of PHP code with ?>.
>>>
>>>> There's no reason to kill good
>>>> code that passes its tests just because it uses inline HTML. I won't
>>>> even know I have that code in my project from some third party library
>>>> until I find out the hard way. No, just no. (:
>>>
>>> I'm not trying to kill anything. In fact what I'm proposing would be a
>>> smooth transition to something that is already done. The difference is
>>> at some point you won't be able to do this:
>>>
>>> <?php
>>> class Object
>>> {
>>> public function output()
>>> {
>>> ?>
>>> Print me!
>>> <?php
>>> }
>>> }
>>>
>>> I cringe every time I see this. There is no excuse since we have here/nowdocs.
>>>
>>> For people that use PHP as a template there can be other options. I'm
>>> not totally against a new keyword, but I am against a new keyword for
>>> including normal PHP code. It just doesn't make sense. No matter what
>>> you name it (require_code, require_file, require_path) it's damned
>>> confusing. If you did it the other way around its much clearer:
>>> require_template.
>>>
>>> With require_template you're also free to expand template
>>> functionality while keeping code clearly separated.
>>>
>>>> I did propose one new keyword, but by proposing one keyword with a
>>>> future-friendly syntax instead of four new keywords I'm attempting to
>>>> help with the pollution problem.
>>>
>>> It's not as much as adding a keyword as it is what keyword you're adding.
>>>
>>> I hope the way I've explained things makes sense.
>>>
>>> Luke
>>>
>>>>
>>>> On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott <[email protected]> wrote:
>>>>> Tom,
>>>>>
>>>>> As I've said before I don't think new keywords are the answer. They
>>>>> will just pollute the language even further.
>>>>>
>>>>> I also don't think an ini setting is a bad thing either. It is often
>>>>> used in PHP as a way to transition from way of doing things to
>>>>> another. First you introduce it with it being off by default, then on
>>>>> by default, then deprecate the old behavior. It's quite normal in
>>>>> PHP's history.
>>>>>
>>>>> In another email someone mentioned doing two rfcs. In both cases are
>>>>> we talking about removing <?php ? Because it's become somewhat
>>>>> confusing to keep track of what is being talked about. If that is the
>>>>> case, continue reading.
>>>>>
>>>>> I would prefer the starting <?php tag be optional rather than removed.
>>>>> Just explicitly forbid the ending ?> tag and treat text before the
>>>>> opening <?php tag differently. Perhaps ignore it (rather than print)
>>>>> or throw an error.
>>>>>
>>>>> That is at least how I would prefer the "code" mode as most
>>>>> non-template files only start with <?php. It allows for backwards
>>>>> compatibility.
>>>>>
>>>>> If you must add keywords it should be something like require_template
>>>>> NOT require_code/require_file. Templates are the exception, not the
>>>>> norm.
>>>>>
>>>>> Luke Scott
>>>>>
>>>>> On Apr 8, 2012, at 9:32 AM, Tom Boutell <[email protected]> wrote:
>>>>>
>>>>>> I have written an RFC proposing backwards-compatible support for
>>>>>> source files without an opening <?php tag:
>>>>>>
>>>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>>>>
>>>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>>>>>> what the requirements are to get it added to the "Under Discussion"
>>>>>> session and get the ball rolling formally. Please enlighten and I'll
>>>>>> do whatever is required.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> --
>>>>>> Tom Boutell
>>>>>> P'unk Avenue
>>>>>> 215 755 1330
>>>>>> punkave.com
>>>>>> window.punkave.com
>>>>>>
>>>>>> --
>>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Tom Boutell
>>>> P'unk Avenue
>>>> 215 755 1330
>>>> punkave.com
>>>> window.punkave.com
>>>>
>>>> --
>>>> PHP Internals - PHP Runtime Development Mailing List
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>
>>
>>
>> --
>> Tom Boutell
>> P'unk Avenue
>> 215 755 1330
>> punkave.com
>> window.punkave.com
>
>
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> 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
Ralph Schindler
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 07:50PM
Hey Tom,

An idea, why not overload require/include with a second parameter that
simply enforces an include mode. For example

// in some autoloader (include, requires, and *_onces)
include $pathToFile, INCLUDE_MODE_PHP_ONLY;

This would tell the parser/executor to start in PHP mode and never leave
it, that way, ending tags would throw a runtime/execution error.

Other constants and behaviors could be:

INCLUDE_MODE_PHP_START;
INCLUDE_MODE_PASSTRHOUGH_START; (the current and default behavior)

This would have the least amount of impact on BC, and seeminlyg would be
a friendly change to the lexer/syntax.

Thoughts?

-ralph



On 4/9/12 12:23 PM, Tom Boutell wrote:
> Also, your objection - that 'require_code' is confusing - would most
> likely be an issue for a handful of people who write autoloaders.
> Those clean PHP class files are almost always autoloaded.
>
> On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell<[email protected]> wrote:
>> I see what you're saying, but you're proposing a new keyword to
>> include code that does what plain old 'require' does now (assuming
>> it's not a nice clean class file that is being included). Which means
>> that valid code today is busted code once this feature comes out. That
>> seems like a very hard sell.
>>
>> On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott<[email protected]> wrote:
>>> On Apr 9, 2012, at 9:16 AM, Tom Boutell<[email protected]> wrote:
>>>
>>>> It sounds like you are proposing to gradually kill the use of PHP for
>>>> templating entirely, which I don't think is something people would
>>>> vote for.
>>>
>>> I'm not saying that at all. I'm saying that PHP code should be clearly
>>> separated from template code.<?php should be optional at the start of
>>> the file and IF a keyword should be added it should be for templates
>>> and short-tags.
>>>
>>> 99% of modern PHP code is going to be classes that start with<?php
>>> and omit the ending ?> (since PHP 5 due to how easy it is for white
>>> space to end up on the tail end of a file). this is even the case with
>>> procedural code.
>>>
>>> Half the PHP frameworks out there have their own template engine
>>> because they can do a lot more than what short tags offer. Example:
>>> Twig offers template inheritance.
>>>
>>> Introducing a keyword for PHP code without the<?php tag is
>>> impractical. It makes much more sense to have a keyword for templates.
>>>
>>> For non-template code the starting<?php tag should always work as it
>>> has before for backwards compatibility. The difference is you cannot
>>> use ?> and text before the opening<?php tag is either ignored or
>>> throws an error.
>>>
>>>> I sometimes use perfectly good older frameworks that do use
>>>> .php files for templating in a reasonable way, and I'm one of the
>>>> advocates for migrating away from starting everything with<?php. I
>>>> would have to vote against it myself.
>>>
>>> And those files can be included with something like require_template
>>> or you can turn off the option in the ini file.
>>>
>>> The point is in EITHER MODE a php file that starts with<?php will
>>> work as it did before. The new mode would just disallow you to break
>>> out of PHP code with ?>.
>>>
>>>> There's no reason to kill good
>>>> code that passes its tests just because it uses inline HTML. I won't
>>>> even know I have that code in my project from some third party library
>>>> until I find out the hard way. No, just no. (:
>>>
>>> I'm not trying to kill anything. In fact what I'm proposing would be a
>>> smooth transition to something that is already done. The difference is
>>> at some point you won't be able to do this:
>>>
>>> <?php
>>> class Object
>>> {
>>> public function output()
>>> {
>>> ?>
>>> Print me!
>>> <?php
>>> }
>>> }
>>>
>>> I cringe every time I see this. There is no excuse since we have here/nowdocs.
>>>
>>> For people that use PHP as a template there can be other options. I'm
>>> not totally against a new keyword, but I am against a new keyword for
>>> including normal PHP code. It just doesn't make sense. No matter what
>>> you name it (require_code, require_file, require_path) it's damned
>>> confusing. If you did it the other way around its much clearer:
>>> require_template.
>>>
>>> With require_template you're also free to expand template
>>> functionality while keeping code clearly separated.
>>>
>>>> I did propose one new keyword, but by proposing one keyword with a
>>>> future-friendly syntax instead of four new keywords I'm attempting to
>>>> help with the pollution problem.
>>>
>>> It's not as much as adding a keyword as it is what keyword you're adding.
>>>
>>> I hope the way I've explained things makes sense.
>>>
>>> Luke
>>>
>>>>
>>>> On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott<[email protected]> wrote:
>>>>> Tom,
>>>>>
>>>>> As I've said before I don't think new keywords are the answer. They
>>>>> will just pollute the language even further.
>>>>>
>>>>> I also don't think an ini setting is a bad thing either. It is often
>>>>> used in PHP as a way to transition from way of doing things to
>>>>> another. First you introduce it with it being off by default, then on
>>>>> by default, then deprecate the old behavior. It's quite normal in
>>>>> PHP's history.
>>>>>
>>>>> In another email someone mentioned doing two rfcs. In both cases are
>>>>> we talking about removing<?php ? Because it's become somewhat
>>>>> confusing to keep track of what is being talked about. If that is the
>>>>> case, continue reading.
>>>>>
>>>>> I would prefer the starting<?php tag be optional rather than removed.
>>>>> Just explicitly forbid the ending ?> tag and treat text before the
>>>>> opening<?php tag differently. Perhaps ignore it (rather than print)
>>>>> or throw an error.
>>>>>
>>>>> That is at least how I would prefer the "code" mode as most
>>>>> non-template files only start with<?php. It allows for backwards
>>>>> compatibility.
>>>>>
>>>>> If you must add keywords it should be something like require_template
>>>>> NOT require_code/require_file. Templates are the exception, not the
>>>>> norm.
>>>>>
>>>>> Luke Scott
>>>>>
>>>>> On Apr 8, 2012, at 9:32 AM, Tom Boutell<[email protected]> wrote:
>>>>>
>>>>>> I have written an RFC proposing backwards-compatible support for
>>>>>> source files without an opening<?php tag:
>>>>>>
>>>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>>>>
>>>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>>>>>> what the requirements are to get it added to the "Under Discussion"
>>>>>> session and get the ball rolling formally. Please enlighten and I'll
>>>>>> do whatever is required.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> --
>>>>>> Tom Boutell
>>>>>> P'unk Avenue
>>>>>> 215 755 1330
>>>>>> punkave.com
>>>>>> window.punkave.com
>>>>>>
>>>>>> --
>>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Tom Boutell
>>>> P'unk Avenue
>>>> 215 755 1330
>>>> punkave.com
>>>> window.punkave.com
>>>>
>>>> --
>>>> PHP Internals - PHP Runtime Development Mailing List
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>
>>
>>
>> --
>> Tom Boutell
>> P'unk Avenue
>> 215 755 1330
>> punkave.com
>> window.punkave.com
>
>
>


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Luke Scott
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 08:00PM
On Apr 9, 2012, at 10:44 AM, Ralph Schindler <[email protected]> wrote:

> Hey Tom,
>
> An idea, why not overload require/include with a second parameter that simply enforces an include mode. For example
>
> // in some autoloader (include, requires, and *_onces)
> include $pathToFile, INCLUDE_MODE_PHP_ONLY;
>
> This would tell the parser/executor to start in PHP mode and never leave it, that way, ending tags would throw a runtime/execution error.
>
> Other constants and behaviors could be:
>
> INCLUDE_MODE_PHP_START;
> INCLUDE_MODE_PASSTRHOUGH_START; (the current and default behavior)
>
> This would have the least amount of impact on BC, and seeminlyg would be a friendly change to the lexer/syntax.
>
> Thoughts?


If this were to happen:

- I would prefer much shorter elegant constants.

- A constant for suppressing warnings thrown by include without
suppressing warnings/errors by the actual file -- I think we can all
agree @include is counter productive since it does much more that
suppress warnings thrown by include (even parse errors!).

Luke


>
> -ralph
>
>
>
> On 4/9/12 12:23 PM, Tom Boutell wrote:
>> Also, your objection - that 'require_code' is confusing - would most
>> likely be an issue for a handful of people who write autoloaders.
>> Those clean PHP class files are almost always autoloaded.
>>
>> On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell<[email protected]> wrote:
>>> I see what you're saying, but you're proposing a new keyword to
>>> include code that does what plain old 'require' does now (assuming
>>> it's not a nice clean class file that is being included). Which means
>>> that valid code today is busted code once this feature comes out. That
>>> seems like a very hard sell.
>>>
>>> On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott<[email protected]> wrote:
>>>> On Apr 9, 2012, at 9:16 AM, Tom Boutell<[email protected]> wrote:
>>>>
>>>>> It sounds like you are proposing to gradually kill the use of PHP for
>>>>> templating entirely, which I don't think is something people would
>>>>> vote for.
>>>>
>>>> I'm not saying that at all. I'm saying that PHP code should be clearly
>>>> separated from template code.<?php should be optional at the start of
>>>> the file and IF a keyword should be added it should be for templates
>>>> and short-tags.
>>>>
>>>> 99% of modern PHP code is going to be classes that start with<?php
>>>> and omit the ending ?> (since PHP 5 due to how easy it is for white
>>>> space to end up on the tail end of a file). this is even the case with
>>>> procedural code.
>>>>
>>>> Half the PHP frameworks out there have their own template engine
>>>> because they can do a lot more than what short tags offer. Example:
>>>> Twig offers template inheritance.
>>>>
>>>> Introducing a keyword for PHP code without the<?php tag is
>>>> impractical. It makes much more sense to have a keyword for templates.
>>>>
>>>> For non-template code the starting<?php tag should always work as it
>>>> has before for backwards compatibility. The difference is you cannot
>>>> use ?> and text before the opening<?php tag is either ignored or
>>>> throws an error.
>>>>
>>>>> I sometimes use perfectly good older frameworks that do use
>>>>> .php files for templating in a reasonable way, and I'm one of the
>>>>> advocates for migrating away from starting everything with<?php. I
>>>>> would have to vote against it myself.
>>>>
>>>> And those files can be included with something like require_template
>>>> or you can turn off the option in the ini file.
>>>>
>>>> The point is in EITHER MODE a php file that starts with<?php will
>>>> work as it did before. The new mode would just disallow you to break
>>>> out of PHP code with ?>.
>>>>
>>>>> There's no reason to kill good
>>>>> code that passes its tests just because it uses inline HTML. I won't
>>>>> even know I have that code in my project from some third party library
>>>>> until I find out the hard way. No, just no. (:
>>>>
>>>> I'm not trying to kill anything. In fact what I'm proposing would be a
>>>> smooth transition to something that is already done. The difference is
>>>> at some point you won't be able to do this:
>>>>
>>>> <?php
>>>> class Object
>>>> {
>>>> public function output()
>>>> {
>>>> ?>
>>>> Print me!
>>>> <?php
>>>> }
>>>> }
>>>>
>>>> I cringe every time I see this. There is no excuse since we have here/nowdocs.
>>>>
>>>> For people that use PHP as a template there can be other options. I'm
>>>> not totally against a new keyword, but I am against a new keyword for
>>>> including normal PHP code. It just doesn't make sense. No matter what
>>>> you name it (require_code, require_file, require_path) it's damned
>>>> confusing. If you did it the other way around its much clearer:
>>>> require_template.
>>>>
>>>> With require_template you're also free to expand template
>>>> functionality while keeping code clearly separated.
>>>>
>>>>> I did propose one new keyword, but by proposing one keyword with a
>>>>> future-friendly syntax instead of four new keywords I'm attempting to
>>>>> help with the pollution problem.
>>>>
>>>> It's not as much as adding a keyword as it is what keyword you're adding.
>>>>
>>>> I hope the way I've explained things makes sense.
>>>>
>>>> Luke
>>>>
>>>>>
>>>>> On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott<[email protected]> wrote:
>>>>>> Tom,
>>>>>>
>>>>>> As I've said before I don't think new keywords are the answer. They
>>>>>> will just pollute the language even further.
>>>>>>
>>>>>> I also don't think an ini setting is a bad thing either. It is often
>>>>>> used in PHP as a way to transition from way of doing things to
>>>>>> another. First you introduce it with it being off by default, then on
>>>>>> by default, then deprecate the old behavior. It's quite normal in
>>>>>> PHP's history.
>>>>>>
>>>>>> In another email someone mentioned doing two rfcs. In both cases are
>>>>>> we talking about removing<?php ? Because it's become somewhat
>>>>>> confusing to keep track of what is being talked about. If that is the
>>>>>> case, continue reading.
>>>>>>
>>>>>> I would prefer the starting<?php tag be optional rather than removed.
>>>>>> Just explicitly forbid the ending ?> tag and treat text before the
>>>>>> opening<?php tag differently. Perhaps ignore it (rather than print)
>>>>>> or throw an error.
>>>>>>
>>>>>> That is at least how I would prefer the "code" mode as most
>>>>>> non-template files only start with<?php. It allows for backwards
>>>>>> compatibility.
>>>>>>
>>>>>> If you must add keywords it should be something like require_template
>>>>>> NOT require_code/require_file. Templates are the exception, not the
>>>>>> norm.
>>>>>>
>>>>>> Luke Scott
>>>>>>
>>>>>> On Apr 8, 2012, at 9:32 AM, Tom Boutell<[email protected]> wrote:
>>>>>>
>>>>>>> I have written an RFC proposing backwards-compatible support for
>>>>>>> source files without an opening<?php tag:
>>>>>>>
>>>>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>>>>>
>>>>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>>>>>>> what the requirements are to get it added to the "Under Discussion"
>>>>>>> session and get the ball rolling formally. Please enlighten and I'll
>>>>>>> do whatever is required.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> --
>>>>>>> Tom Boutell
>>>>>>> P'unk Avenue
>>>>>>> 215 755 1330
>>>>>>> punkave.com
>>>>>>> window.punkave.com
>>>>>>>
>>>>>>> --
>>>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Tom Boutell
>>>>> P'unk Avenue
>>>>> 215 755 1330
>>>>> punkave.com
>>>>> window.punkave.com
>>>>>
>>>>> --
>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>
>>>
>>>
>>>
>>> --
>>> Tom Boutell
>>> P'unk Avenue
>>> 215 755 1330
>>> punkave.com
>>> window.punkave.com
>>
>>
>>
>
>
> --
> 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
Chris Stockton
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 08:30PM
Hello,

On Mon, Apr 9, 2012 at 10:43 AM, Ralph Schindler
<[email protected]> wrote:
> Hey Tom,
>
> An idea, why not overload require/include with a second parameter that
> simply enforces an include mode.  For example
>
> // in some autoloader (include, requires, and *_onces)
> include $pathToFile, INCLUDE_MODE_PHP_ONLY;
>
> This would tell the parser/executor to start in PHP mode and never leave it,
> that way, ending tags would throw a runtime/execution error.
>
> Other constants and behaviors could be:
>
>  INCLUDE_MODE_PHP_START;
>  INCLUDE_MODE_PASSTRHOUGH_START; (the current and default behavior)
>
> This would have the least amount of impact on BC, and seeminlyg would be a
> friendly change to the lexer/syntax.
>
> Thoughts?
>
> -ralph
>
>

Although I am not very interested in this feature, if it is
implemented I like the idea of flags instead of introducing new
keywords. Maintaining backwards compatibility would be great
considering the benefit to the feature to be completely honest (and in
disagreement to many people, but I do understand the reasoning for
everyone's interest in it) is extremely minor in my eyes.

In addition I would suggest maybe using PHP_INCLUDE_* as a place for
these constants to live.

-Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tom Boutell
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 08:30PM
Ralph, you make good points. And Luke's opposition to my new keyword
is probably going to be shared by others (like Chris who just chimed
in).

So the more I think about it, the more a set of constants that can be
OR'd together is a better idea than my associative array proposal. And
it's best to keep the original four keywords, adding the second,
optional parameter as a way of passing a combination of flags that
alter their behavior.

Also that set of bits could include the 'once' and 'warning' flags, so
if you really want to just use the 'require' keyword and determine
dynamically which behavior you get, you can. So there are no new
keywords needed.

Also, the presence of any bit that is not recognized by this version
of PHP should be an error. It's better to stop than to completely
misparse a file (:

I don't think long-ish constants are a real problem since this
functionality would very likely be written just a few times in
autoloaders (as is typical in almost any project that would be
interested in .phpc files in the first place) rather than repeatedly
all over the place in every file (as with old-fashioned uses of
'require', and various templating situations).

I will revise the RFC shortly.

On Mon, Apr 9, 2012 at 1:51 PM, Luke Scott <[email protected]> wrote:
> On Apr 9, 2012, at 10:44 AM, Ralph Schindler <[email protected]> wrote:
>
>> Hey Tom,
>>
>> An idea, why not overload require/include with a second parameter that simply enforces an include mode.  For example
>>
>> // in some autoloader (include, requires, and *_onces)
>> include $pathToFile, INCLUDE_MODE_PHP_ONLY;
>>
>> This would tell the parser/executor to start in PHP mode and never leave it, that way, ending tags would throw a runtime/execution error.
>>
>> Other constants and behaviors could be:
>>
>>  INCLUDE_MODE_PHP_START;
>>  INCLUDE_MODE_PASSTRHOUGH_START; (the current and default behavior)
>>
>> This would have the least amount of impact on BC, and seeminlyg would be a friendly change to the lexer/syntax.
>>
>> Thoughts?
>
>
> If this were to happen:
>
> - I would prefer much shorter elegant constants.
>
> - A constant for suppressing warnings thrown by include without
> suppressing warnings/errors by the actual file -- I think we can all
> agree @include is counter productive since it does much more that
> suppress warnings thrown by include (even parse errors!).
>
> Luke
>
>
>>
>> -ralph
>>
>>
>>
>> On 4/9/12 12:23 PM, Tom Boutell wrote:
>>> Also, your objection - that 'require_code' is confusing - would most
>>> likely be an issue for a handful of people who write autoloaders.
>>> Those clean PHP class files are almost always autoloaded.
>>>
>>> On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell<[email protected]>  wrote:
>>>> I see what you're saying, but you're proposing a new keyword to
>>>> include code that does what plain old 'require' does now (assuming
>>>> it's not a nice clean class file that is being included). Which means
>>>> that valid code today is busted code once this feature comes out. That
>>>> seems like a very hard sell.
>>>>
>>>> On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott<[email protected]>  wrote:
>>>>> On Apr 9, 2012, at 9:16 AM, Tom Boutell<[email protected]>  wrote:
>>>>>
>>>>>> It sounds like you are proposing to gradually kill the use of PHP for
>>>>>> templating entirely, which I don't think is something people would
>>>>>> vote for.
>>>>>
>>>>> I'm not saying that at all. I'm saying that PHP code should be clearly
>>>>> separated from template code.<?php should be optional at the start of
>>>>> the file and IF a keyword should be added it should be for templates
>>>>> and short-tags.
>>>>>
>>>>> 99% of modern PHP code is going to be classes that start with<?php
>>>>> and omit the ending ?>  (since PHP 5 due to how easy it is for white
>>>>> space to end up on the tail end of a file). this is even the case with
>>>>> procedural code.
>>>>>
>>>>> Half the PHP frameworks out there have their own template engine
>>>>> because they can do a lot more than what short tags offer. Example:
>>>>> Twig offers template inheritance.
>>>>>
>>>>> Introducing a keyword for PHP code without the<?php tag is
>>>>> impractical. It makes much more sense to have a keyword for templates..
>>>>>
>>>>> For non-template code the starting<?php tag should always work as it
>>>>> has before for backwards compatibility. The difference is you cannot
>>>>> use ?>  and text before the opening<?php tag is either ignored or
>>>>> throws an error.
>>>>>
>>>>>> I sometimes use perfectly good older frameworks that do use
>>>>>> .php files for templating in a reasonable way, and I'm one of the
>>>>>> advocates for migrating away from starting everything with<?php. I
>>>>>> would have to vote against it myself.
>>>>>
>>>>> And those files can be included with something like require_template
>>>>> or you can turn off the option in the ini file.
>>>>>
>>>>> The point is in EITHER MODE a php file that starts with<?php will
>>>>> work as it did before. The new mode would just disallow you to break
>>>>> out of PHP code with ?>.
>>>>>
>>>>>> There's no reason to kill good
>>>>>> code that passes its tests just because it uses inline HTML. I won't
>>>>>> even know I have that code in my project from some third party library
>>>>>> until I find out the hard way. No, just no. (:
>>>>>
>>>>> I'm not trying to kill anything. In fact what I'm proposing would be a
>>>>> smooth transition to something that is already done. The difference is
>>>>> at some point you won't be able to do this:
>>>>>
>>>>> <?php
>>>>> class Object
>>>>> {
>>>>>    public function output()
>>>>>    {
>>>>> ?>
>>>>> Print me!
>>>>> <?php
>>>>>    }
>>>>> }
>>>>>
>>>>> I cringe every time I see this. There is no excuse since we have here/nowdocs.
>>>>>
>>>>> For people that use PHP as a template there can be other options. I'm
>>>>> not totally against a new keyword, but I am against a new keyword for
>>>>> including normal PHP code. It just doesn't make sense. No matter what
>>>>> you name it (require_code, require_file, require_path) it's damned
>>>>> confusing. If you did it the other way around its much clearer:
>>>>> require_template.
>>>>>
>>>>> With require_template you're also free to expand template
>>>>> functionality while keeping code clearly separated.
>>>>>
>>>>>> I did propose one new keyword, but by proposing one keyword with a
>>>>>> future-friendly syntax instead of four new keywords I'm attempting to
>>>>>> help with the pollution problem.
>>>>>
>>>>> It's not as much as adding a keyword as it is what keyword you're adding.
>>>>>
>>>>> I hope the way I've explained things makes sense.
>>>>>
>>>>> Luke
>>>>>
>>>>>>
>>>>>> On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott<[email protected]>  wrote:
>>>>>>> Tom,
>>>>>>>
>>>>>>> As I've said before I don't think new keywords are the answer. They
>>>>>>> will just pollute the language even further.
>>>>>>>
>>>>>>> I also don't think an ini setting is a bad thing either. It is often
>>>>>>> used in PHP as a way to transition from way of doing things to
>>>>>>> another. First you introduce it with it being off by default, then on
>>>>>>> by default, then deprecate the old behavior. It's quite normal in
>>>>>>> PHP's history.
>>>>>>>
>>>>>>> In another email someone mentioned doing two rfcs. In both cases are
>>>>>>> we talking about removing<?php ? Because it's become somewhat
>>>>>>> confusing to keep track of what is being talked about. If that is the
>>>>>>> case, continue reading.
>>>>>>>
>>>>>>> I would prefer the starting<?php tag be optional rather than removed.
>>>>>>> Just explicitly forbid the ending ?>  tag and treat text before the
>>>>>>> opening<?php tag differently. Perhaps ignore it (rather than print)
>>>>>>> or throw an error.
>>>>>>>
>>>>>>> That is at least how I would prefer the "code" mode as most
>>>>>>> non-template files only start with<?php. It allows for backwards
>>>>>>> compatibility.
>>>>>>>
>>>>>>> If you must add keywords it should be something like require_template
>>>>>>> NOT require_code/require_file. Templates are the exception, not the
>>>>>>> norm.
>>>>>>>
>>>>>>> Luke Scott
>>>>>>>
>>>>>>> On Apr 8, 2012, at 9:32 AM, Tom Boutell<[email protected]>  wrote:
>>>>>>>
>>>>>>>> I have written an RFC proposing backwards-compatible support for
>>>>>>>> source files without an opening<?php tag:
>>>>>>>>
>>>>>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>>>>>>
>>>>>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>>>>>>>> what the requirements are to get it added to the "Under Discussion"
>>>>>>>> session and get the ball rolling formally. Please enlighten and I'll
>>>>>>>> do whatever is required.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> --
>>>>>>>> Tom Boutell
>>>>>>>> P'unk Avenue
>>>>>>>> 215 755 1330
>>>>>>>> punkave.com
>>>>>>>> window.punkave.com
>>>>>>>>
>>>>>>>> --
>>>>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Tom Boutell
>>>>>> P'unk Avenue
>>>>>> 215 755 1330
>>>>>> punkave.com
>>>>>> window.punkave.com
>>>>>>
>>>>>> --
>>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Tom Boutell
>>>> P'unk Avenue
>>>> 215 755 1330
>>>> punkave.com
>>>> window.punkave.com
>>>
>>>
>>>
>>
>>
>> --
>> 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
>



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ángel González
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 09:20PM
On 09/04/12 20:23, Chris Stockton wrote:
> Hello,
> Although I am not very interested in this feature, if it is
> implemented I like the idea of flags instead of introducing new
> keywords. Maintaining backwards compatibility would be great
> considering the benefit to the feature to be completely honest (and in
> disagreement to many people, but I do understand the reasoning for
> everyone's interest in it) is extremely minor in my eyes.
>
> In addition I would suggest maybe using PHP_INCLUDE_* as a place for
> these constants to live.
>
> -Chris
That would still be a parse error.
Either
include "file.php", 5;
or
include ("file.php", 42);

Fails with a parse error about unexpected ','

On the other hand, a new keyword can be written in a backwards
compatible way by making it look like a function call in a non-taken branch:

*if ( version_compare(PHP_VERSION*, '5.5', '<') )
include_once $file;
else
require_code($file, array( 'once'=>true, 'warn' => 'ignore' ) );


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ralph Schindler
Re: [PHP-DEV] RFC: source files without opening tag
April 09, 2012 09:30PM
> autoloaders (as is typical in almost any project that would be
> interested in .phpc files in the first place) rather than repeatedly

I am partial to file.p btw.
PHP without the HP, or Hypertext Pre-Processing- whatever that is! ;)
In fact, it could mean PHP without the Html Passthrough. You get the point.

phpc to me seems to imply a compile cache, like .pyc

-ralph


> all over the place in every file (as with old-fashioned uses of
> 'require', and various templating situations).
>
> I will revise the RFC shortly.
>



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login