FAQ

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

Tom Boutell
Apr 8, 2012 at 4:32 pm
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
reply

Search Discussions

108 responses

  • Kris Craig at Apr 8, 2012 at 9:10 pm
    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" 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 at Apr 8, 2012 at 9:25 pm
    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 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" 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
  • Yasuo Ohgaki at Apr 8, 2012 at 9:50 pm
    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 <tom@punkave.com>:
    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
  • Yasuo Ohgaki at Apr 8, 2012 at 9:56 pm
    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 <yohgaki@ohgaki.net>:
    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 <tom@punkave.com>:
    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 at Apr 8, 2012 at 10:20 pm
    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 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 <yohgaki@ohgaki.net>:
    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 <tom@punkave.com>:
    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
  • Yasuo Ohgaki at Apr 8, 2012 at 10:46 pm
    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 <tom@punkave.com>:
    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 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 <yohgaki@ohgaki.net>:
    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 <tom@punkave.com>:
    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 at Apr 8, 2012 at 11:14 pm
    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 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 <tom@punkave.com>:
    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 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 <yohgaki@ohgaki.net>:
    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 <tom@punkave.com>:
    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
  • Kris Craig at Apr 9, 2012 at 5:16 am
    Tom,
    On Sun, Apr 8, 2012 at 4:14 PM, Tom Boutell 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 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 <tom@punkave.com>:
    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 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 <yohgaki@ohgaki.net>:
    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 <tom@punkave.com>:
    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 at Apr 9, 2012 at 10:55 am
    .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 wrote:

    Tom,

    On Sun, Apr 8, 2012 at 4:14 PM, Tom Boutell 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 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 <tom@punkave.com>:
    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 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 <yohgaki@ohgaki.net>:
    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 <tom@punkave.com>:
    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 at Apr 9, 2012 at 5:49 am
    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 <tom@punkave.com>:
    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 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 <tom@punkave.com>:
    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 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 <yohgaki@ohgaki.net>:
    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 <tom@punkave.com>:
    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
  • Yasuo Ohgaki at Apr 9, 2012 at 6:18 am
    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
  • Tom Boutell at Apr 9, 2012 at 10:57 am
    I think separating these rfcs makes sense, thanks.

    Sent from my iPhone
    On Apr 9, 2012, at 2:17 AM, Yasuo Ohgaki 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
  • Arvids Godjuks at Apr 10, 2012 at 12:07 am
    I have a question - does it really bother people to type the <?php tag? I
    kind*a don't do that for how long, 4-5 years? Every IDE and every damn
    decent code editor does that for you. Hell, they even can create a template
    file for you!
    Some arguments are just plain silly.

    The point about file include attacks on the other hand is valid. Including
    code without the <?php tag does protect from things like uploading an image
    and exploiting a vurnelable include to execute the code. On the other hand
    you have the problem of BC and libraries with the <?php tag everythere - I
    haven't seen any real discussion about this. And beleve me, this will be
    the "WTF?!".

    PHp native templates are also a big factor, i personally do not use any
    template engine - plain php is pretty damn good if combined with good tools
    (in my case Yii framework provides great stuff to work with).

    The most thing i fear that changing this will add a false sence of
    security. If you include a file based on a route (witch we usually do) -
    you have to check your input tripple-time and make sure it does not try to
    point elsewhere. If not, the people out there will find a way to use thet
    vurneability, it just would not be a. gif file, but something else. Not to
    say some just configure to run any file as a PHP file.
  • Yasuo Ohgaki at Apr 10, 2012 at 12:19 am
    Hi,

    2012/4/10 Arvids Godjuks <arvids.godjuks@gmail.com>:
    I have a question - does it really bother people to type the <?php tag? I
    kind*a don't do that for how long, 4-5 years? Every IDE and every damn
    decent code editor does that for you. Hell, they even can create a template
    file for you!
    Some arguments are just plain silly.

    The point about file include attacks on the other hand is valid. Including
    code without the <?php tag does protect from things like uploading an image
    and exploiting a vurnelable include to execute the code. On the other hand
    you have the problem of BC and libraries with the <?php tag everythere - I
    haven't seen any real discussion about this. And beleve me, this will be
    the "WTF?!".
    I agree.

    Therefore, current behavior is the default. If newer code written with a
    little care, the code is compatible for both embedded and non-embedded
    modes. Those who are not willing to write opening TAG, it is possible a
    single ini_set() or command line option, too.

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

    Comments are welcome.

    Regards,

    --
    Yasuo Ohgaki
    yohgaki@ohgaki.net
    PHp native templates are also a big factor, i personally do not use any
    template engine - plain php is pretty damn good if combined with good tools
    (in my case Yii framework provides great stuff to work with).

    The most thing i fear that changing this will add a false sence of
    security. If you include a file based on a route (witch we usually do) -
    you have to check your input tripple-time and make sure it does not try to
    point elsewhere. If not, the people out there will find a way to use thet
    vurneability, it just would not be a. gif file, but something else. Not to
    say some just configure to run any file as a PHP file.
  • Tom Boutell at Apr 9, 2012 at 11:29 am
    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
  • Ángel González at Apr 9, 2012 at 12:21 pm

    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
  • Rick WIdmer at Apr 9, 2012 at 1:16 pm
    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.
  • Tom Boutell at Apr 9, 2012 at 1:40 pm

    On Mon, Apr 9, 2012 at 9:16 AM, Rick WIdmer 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
  • Crocodile at Apr 9, 2012 at 2:02 pm
    IDE creators will definitely be excited with this new feature.

    2012/4/9 Tom Boutell <tom@punkave.com>
    On Mon, Apr 9, 2012 at 9:16 AM, Rick WIdmer 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 at Apr 9, 2012 at 3:43 pm
    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 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 at Apr 9, 2012 at 4:16 pm
    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 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 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
  • Luke Scott at Apr 9, 2012 at 5:11 pm

    On Apr 9, 2012, at 9:16 AM, Tom Boutell 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 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 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 at Apr 9, 2012 at 5:22 pm
    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 wrote:
    On Apr 9, 2012, at 9:16 AM, Tom Boutell 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 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 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 at Apr 9, 2012 at 5:23 pm
    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 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 wrote:
    On Apr 9, 2012, at 9:16 AM, Tom Boutell 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 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 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
  • Luke Scott at Apr 9, 2012 at 5:36 pm

    On Apr 9, 2012, at 10:23 AM, 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.
    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 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 wrote:
    On Apr 9, 2012, at 9:16 AM, Tom Boutell 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 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 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
  • Ángel González at Apr 9, 2012 at 7:27 pm

    On 09/04/12 19:36, Luke Scott wrote:
    On Apr 9, 2012, at 10:23 AM, 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.
    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?
    A php file, of course :)

    You have to look at the keywords you're proposing and try to explain
    then without prior knowledge or documentation.
    But if you come accross them you'd see something like:
    require_code "setup.php";

    Which is much more clear.
    These keywords are also ambiguous. require/include are well understood
    for including code not templates. Not just for PHP.
    PHP has allowed to require HTML forever. Given it's php developers the main
    target, it is not a huge argument that they may get confused by
    require_file
    doing what require has always done.

    I admit require_code for a full HTML file* may be slightly odd, but
    require_file
    is completely aseptic about that.


    * Which should instead have been loaded with readfile()...

    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.
    Except that you're breaking compatibility by designing it the opposite way.
    It may have been the perfect idea if we were designing PHP from scratch, but
    we're not. This is a 17 years old language.
  • Luke Scott at Apr 9, 2012 at 7:57 pm

    On Apr 9, 2012, at 12:27 PM, "Ángel González" wrote:
    On 09/04/12 19:36, Luke Scott wrote:
    On Apr 9, 2012, at 10:23 AM, 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.
    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?
    A php file, of course :)
    I'm sorry but the word "file" is highly non descriptive. Remember to
    consider newcomers to the language as well. Consider also the are
    functions that already make use of this word such as: file,
    file_get_contents, file_put_contents, readfile, etc...
    You have to look at the keywords you're proposing and try to explain
    then without prior knowledge or documentation.
    But if you come accross them you'd see something like:
    require_code "setup.php";

    Which is much more clear.
    You also can't make the assumption that someone is going to learn this
    from existing code.
    These keywords are also ambiguous. require/include are well understood
    for including code not templates. Not just for PHP.
    PHP has allowed to require HTML forever. Given it's php developers the main
    target, it is not a huge argument that they may get confused by
    require_file
    doing what require has always done.
    And it's considered bad practice. A majority of PHP developers avoid
    it. The only time they do this is for templates in very small
    projects. For larger projects using PHP as a template engine is
    unmaintainable.

    If you look at code on Github I'm sure you'll find most code starting
    with <?php and that's it. Perhaps a handful stick ?> at the end... But
    even fewer are going to break out of PHP just to print something.
    Especially with nowdoc.

    We aren't trying to be compatible with PHP 4. Most of what I have said
    has been the case since PHP 5.1. At least 5.2 (which is no longer
    supported).

    Luke
    I admit require_code for a full HTML file* may be slightly odd, but
    require_file
    is completely aseptic about that.


    * Which should instead have been loaded with readfile()...

    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.
    Except that you're breaking compatibility by designing it the opposite way.
    It may have been the perfect idea if we were designing PHP from scratch, but
    we're not. This is a 17 years old language.

  • Ralph Schindler at Apr 9, 2012 at 5:43 pm
    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 Boutellwrote:
    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 Scottwrote:
    On Apr 9, 2012, at 9:16 AM, Tom Boutellwrote:
    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 Scottwrote:
    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 Boutellwrote:
    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
  • Luke Scott at Apr 9, 2012 at 5:51 pm

    On Apr 9, 2012, at 10:44 AM, Ralph Schindler 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 Boutellwrote:
    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 Scottwrote:
    On Apr 9, 2012, at 9:16 AM, Tom Boutellwrote:
    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 Scottwrote:
    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 Boutellwrote:
    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 at Apr 9, 2012 at 6:26 pm
    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 wrote:
    On Apr 9, 2012, at 10:44 AM, Ralph Schindler 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 Boutellwrote:
    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 Scottwrote:
    On Apr 9, 2012, at 9:16 AM, Tom Boutellwrote:
    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 Scottwrote:
    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 Boutellwrote:
    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
  • Ralph Schindler at Apr 9, 2012 at 7:20 pm

    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.
  • Yasuo Ohgaki at Apr 9, 2012 at 7:37 pm
    Hi,

    Tom's FRC is trying to introduce tag less PHP script.
    However, it does not fix well known PHP vulnerability. i.e. LFI/RFI
    IMHO, this change introduce more complexity and do not solve
    any problem.

    Making PHP tag a non mandatory would solve the well known
    vulnerability and do not introduce any new function. It's also fully
    compatible to existing codes.

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

    There would be many developers/administrators who would
    like to be protected from code like "include $_GET['var']".
    nophptags RFC protects systems from this kind of fatal
    vulnerable codes.

    Regards,

    --
    Yasuo Ohgaki
    yohgaki@ohgaki.net
  • Stas Malyshev at Apr 9, 2012 at 7:38 pm
    Hi!
    Tom's FRC is trying to introduce tag less PHP script.
    However, it does not fix well known PHP vulnerability. i.e. LFI/RFI
    IMHO, this change introduce more complexity and do not solve
    any problem.
    I'm not sure I follow - which PHP vulnerability you are talking about?

    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Yasuo Ohgaki at Apr 9, 2012 at 7:46 pm
    Hi,

    2012/4/10 Stas Malyshev <smalyshev@sugarcrm.com>:
    Hi!
    Tom's FRC is trying to introduce tag less PHP script.
    However, it does not fix well known PHP vulnerability. i.e. LFI/RFI
    IMHO, this change introduce more complexity and do not solve
    any problem.
    I'm not sure I follow - which PHP vulnerability you are talking about?
    Local file includes. (LFI)
    There is a null byte protection for LFI and I really like to the protection.
    It's also beneficial to other problems. However, it would not help codes
    like "include $_REQUEST['var']"

    LFI is fatal vulnerability. It would be better kill the vulnerability
    if we can. IMHO.

    Regards,

    P.S. Mandatory embedded script mode does not make much sense lately.

    --
    Yasuo Ohgaki
    yohgaki@ohgaki.net
  • Stas Malyshev at Apr 9, 2012 at 8:04 pm
    Hi!
    I'm not sure I follow - which PHP vulnerability you are talking about?
    Local file includes. (LFI)
    I'm not sure I understand - where's the vulnerability?
    There is a null byte protection for LFI and I really like to the protection.
    It's also beneficial to other problems. However, it would not help codes
    like "include $_REQUEST['var']"
    Don't write such code. It's like saying exec() function is a
    "vulnerability" in libc. You instruct PHP to run code based on user
    input - that's what PHP will be doing, it's not a "vulnerability" by any
    definition.

    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Yasuo Ohgaki at Apr 9, 2012 at 8:21 pm
    Hi,


    2012/4/10 Stas Malyshev <smalyshev@sugarcrm.com>:
    Hi!
    I'm not sure I follow - which PHP vulnerability you are talking about?
    Local file includes. (LFI)
    I'm not sure I understand - where's the vulnerability?
    There is a null byte protection for LFI and I really like to the protection.
    It's also beneficial to other problems. However, it would not help codes
    like "include $_REQUEST['var']"
    Don't write such code. It's like saying exec() function is a
    "vulnerability" in libc. You instruct PHP to run code based on user
    input - that's what PHP will be doing, it's not a "vulnerability" by any
    definition.
    I agree. Programmer should not write that.

    I would not propose the RFC if PHP is used as embedded languages mainly
    or the vulnerability is non fatal. By making embedded mode non mandatory,
    almost all issues will be gone. Why shouldn't we?

    Regards,

    --
    Yasuo Ohgaki
    yohgaki@ohgaki.net
  • Kris Craig at Apr 9, 2012 at 8:41 pm
    Tom,
    On Mon, Apr 9, 2012 at 1:20 PM, Yasuo Ohgaki wrote:

    Hi,


    2012/4/10 Stas Malyshev <smalyshev@sugarcrm.com>:
    Hi!
    I'm not sure I follow - which PHP vulnerability you are talking about?
    Local file includes. (LFI)
    I'm not sure I understand - where's the vulnerability?
    There is a null byte protection for LFI and I really like to the
    protection.
    It's also beneficial to other problems. However, it would not help codes
    like "include $_REQUEST['var']"
    Don't write such code. It's like saying exec() function is a
    "vulnerability" in libc. You instruct PHP to run code based on user
    input - that's what PHP will be doing, it's not a "vulnerability" by any
    definition.
    I agree. Programmer should not write that.

    I would not propose the RFC if PHP is used as embedded languages mainly
    or the vulnerability is non fatal. By making embedded mode non mandatory,
    almost all issues will be gone. Why shouldn't we?

    Regards,

    --
    Yasuo Ohgaki
    yohgaki@ohgaki.net

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    Honestly, I would suggest just getting rid of "Option 1" altogether. It
    would end up over-complicating this to such a degree that any usefulness it
    might serve would be considerably diminished.

    As for embedded HTML, if you allow the ?> tag in these .phpp files, then
    that pretty much negates the entire purpose of having them to begin with.
    Essentially, you'd just be changing it so that, instead of defaulting to
    "?>" when no tag is present, it defaults to "<?php". I just don't see any
    value in that as a developer.

    A developer should *not* be including in a .phpp file classes that contain
    HTML within the ?> tag, period. If they need to include something that has
    that, they should do it in a regular .php file. An "HTML-less" PHP file
    needs to be exactly that; no direct HTML allowed. Otherwise, the RFC is
    completely and utterly pointless IMHO.


    I think this would be awesome for PHP 6, but I'll have to vote against it
    if you settle on using "Option 1" and/or allow ?> content to be
    embedded/included in .phpp files. If we differentiate based solely on the
    file extension and keep ?> tags out of it, then I'll definitely support it!

    --Kris
  • Rick WIdmer at Apr 9, 2012 at 8:58 pm

    On 4/9/2012 2:41 PM, Kris Craig wrote:
    Honestly, I would suggest just getting rid of "Option 1" altogether. It
    would end up over-complicating this to such a degree that any usefulness it
    might serve would be considerably diminished.

    As for embedded HTML, if you allow the ?> tag in these .phpp files, then
    that pretty much negates the entire purpose of having them to begin with.
    Essentially, you'd just be changing it so that, instead of defaulting to
    "?>" when no tag is present, it defaults to"<?php". I just don't see any
    value in that as a developer.

    A developer should *not* be including in a .phpp file classes that contain
    HTML within the ?> tag, period. If they need to include something that has
    that, they should do it in a regular .php file. An "HTML-less" PHP file
    needs to be exactly that; no direct HTML allowed. Otherwise, the RFC is
    completely and utterly pointless IMHO.


    I think this would be awesome for PHP 6, but I'll have to vote against it
    if you settle on using "Option 1" and/or allow ?> content to be
    embedded/included in .phpp files. If we differentiate based solely on the
    file extension and keep ?> tags out of it, then I'll definitely support it!


    Please forget about file extensions. PHP should not consider file
    extensions. The only reason .php files are executed by PHP is because
    the web browser is configured to pass that extension to PHP rather than
    handle it internally.


    I sincerely hope that any suggestion to eliminate the ability to use PHP
    as a template engine will be met with a veto by the core developers, or
    maybe even another suggestion by the trademark owner of PHP that he will
    not allow the PHP name to be used on such a language.
  • Tom Boutell at Apr 9, 2012 at 9:03 pm
    As others explained before the RFC was drafted, file extensions should
    not be directly respected by PHP because environments differ too much.
    Instead a convention, NOT enforced at the code level, would be
    published and encouraged: .phpc for files that start out in PHP mode,
    and .php for files that start out in HTML mode. PHP would NOT enforce
    this, it would just be an encouraged practice in the writing of
    autoloaders and so on. (Note that autoloaders are already concerned
    with file extensions. They have to be in order to transform a class
    name into a filename.)

    The RFC does not call for putting an end to the traditional use of PHP
    for templates at all, that is still the default behavior when parsing
    PHP. There is an entirely separate RFC that calls for that, but that's
    another thread.
    On Mon, Apr 9, 2012 at 4:58 PM, Rick WIdmer wrote:
    On 4/9/2012 2:41 PM, Kris Craig wrote:
    Honestly, I would suggest just getting rid of "Option 1" altogether.  It
    would end up over-complicating this to such a degree that any usefulness
    it
    might serve would be considerably diminished.

    As for embedded HTML, if you allow the ?>  tag in these .phpp files, then
    that pretty much negates the entire purpose of having them to begin with.
    Essentially, you'd just be changing it so that, instead of defaulting to
    "?>" when no tag is present, it defaults to"<?php".  I just don't see any
    value in that as a developer.

    A developer should *not* be including in a .phpp file classes that contain
    HTML within the ?>  tag, period.  If they need to include something that
    has
    that, they should do it in a regular .php file.  An "HTML-less" PHP file
    needs to be exactly that; no direct HTML allowed.  Otherwise, the RFC is
    completely and utterly pointless IMHO.


    I think this would be awesome for PHP 6, but I'll have to vote against it
    if you settle on using "Option 1" and/or allow ?>  content to be
    embedded/included in .phpp files.  If we differentiate based solely on the
    file extension and keep ?>  tags out of it, then I'll definitely support
    it!



    Please forget about file extensions.  PHP should not consider file
    extensions.  The only reason .php files are executed by PHP is because the
    web browser is configured to pass that extension to PHP rather than handle
    it internally.


    I sincerely hope that any suggestion to eliminate the ability to use PHP as
    a template engine will be met with a veto by the core developers, or maybe
    even another suggestion by the trademark owner of PHP that he will not allow
    the PHP name to be used on such a language.








    --
    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
  • Kris Craig at Apr 9, 2012 at 9:22 pm

    On Mon, Apr 9, 2012 at 2:03 PM, Tom Boutell wrote:

    As others explained before the RFC was drafted, file extensions should
    not be directly respected by PHP because environments differ too much.
    Instead a convention, NOT enforced at the code level, would be
    published and encouraged: .phpc for files that start out in PHP mode,
    and .php for files that start out in HTML mode. PHP would NOT enforce
    this, it would just be an encouraged practice in the writing of
    autoloaders and so on. (Note that autoloaders are already concerned
    with file extensions. They have to be in order to transform a class
    name into a filename.)

    The RFC does not call for putting an end to the traditional use of PHP
    for templates at all, that is still the default behavior when parsing
    PHP. There is an entirely separate RFC that calls for that, but that's
    another thread.
    On Mon, Apr 9, 2012 at 4:58 PM, Rick WIdmer wrote:
    On 4/9/2012 2:41 PM, Kris Craig wrote:
    Honestly, I would suggest just getting rid of "Option 1" altogether. It
    would end up over-complicating this to such a degree that any usefulness
    it
    might serve would be considerably diminished.

    As for embedded HTML, if you allow the ?> tag in these .phpp files,
    then
    that pretty much negates the entire purpose of having them to begin
    with.
    Essentially, you'd just be changing it so that, instead of defaulting to
    "?>" when no tag is present, it defaults to"<?php". I just don't see
    any
    value in that as a developer.

    A developer should *not* be including in a .phpp file classes that
    contain
    HTML within the ?> tag, period. If they need to include something that
    has
    that, they should do it in a regular .php file. An "HTML-less" PHP file
    needs to be exactly that; no direct HTML allowed. Otherwise, the RFC is
    completely and utterly pointless IMHO.


    I think this would be awesome for PHP 6, but I'll have to vote against
    it
    if you settle on using "Option 1" and/or allow ?> content to be
    embedded/included in .phpp files. If we differentiate based solely on
    the
    file extension and keep ?> tags out of it, then I'll definitely support
    it!



    Please forget about file extensions. PHP should not consider file
    extensions. The only reason .php files are executed by PHP is because the
    web browser is configured to pass that extension to PHP rather than handle
    it internally.


    I sincerely hope that any suggestion to eliminate the ability to use PHP as
    a template engine will be met with a veto by the core developers, or maybe
    even another suggestion by the trademark owner of PHP that he will not allow
    the PHP name to be used on such a language.








    --
    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
    Hmm yeah I see your point. Requiring a separate file extension would force
    configuration changes to the webserver. And since not everybody has access
    to that, it would mean that any projects that contain these files would not
    be able to run on hosts like that.

    Ok you've convinced me on the file extension issue, just based on that.
    But I still don't like the new require_* keywords or allowing ?> to be
    mixed-in with PHP scripts that are supposed to be pure code. Again it just
    comes down to a question of usefulness and creating a solution in search of
    a problem.

    What we need is a way to tell the parser that this file is pure PHP. We
    can't use the file extension, so it has to be at the code level. If I'm
    interpreting your proposals correctly, it looks like your approach would be
    to have the including file make this determination. Personally, I think we
    should do the opposite; i.e. this should be defined in the PHP file itself.

    Obviously, it would need to be at the top of the PHP file (whitespace
    notwithstanding). Since we don't want any BC breaks, we at very least need
    it to start with "<?" so that we don't end up parsing anything that wasn't
    mean to be parsed. So how about we keep it simple and just use a single,
    "<?phpp" at the beginning of the file? No ?> would be allowed after that.
    Anything before that (in the file itself) would also be ignored and throw a
    warning.

    This sounds like the best approach, given the limitations involved with
    webserver configurations. I'm still very much against though allowing ?>
    within one of these files (included or otherwise), as it really defeats the
    whole purpose and would just encourage poor architecture without any
    countervailing benefit.

    --Kris
  • Tom Boutell at Apr 9, 2012 at 9:24 pm
    I'm not sure you're wrong about this, but it's definitely an ironic
    suggestion (:
    On Mon, Apr 9, 2012 at 5:22 PM, Kris Craig wrote:

    On Mon, Apr 9, 2012 at 2:03 PM, Tom Boutell wrote:

    As others explained before the RFC was drafted, file extensions should
    not be directly respected by PHP because environments differ too much.
    Instead a convention, NOT enforced at the code level, would be
    published and encouraged: .phpc for files that start out in PHP mode,
    and .php for files that start out in HTML mode. PHP would NOT enforce
    this, it would just be an encouraged practice in the writing of
    autoloaders and so on. (Note that autoloaders are already concerned
    with file extensions. They have to be in order to transform a class
    name into a filename.)

    The RFC does not call for putting an end to the traditional use of PHP
    for templates at all, that is still the default behavior when parsing
    PHP. There is an entirely separate RFC that calls for that, but that's
    another thread.

    On Mon, Apr 9, 2012 at 4:58 PM, Rick WIdmer <vchkpw@developersdesk.com>
    wrote:
    On 4/9/2012 2:41 PM, Kris Craig wrote:
    Honestly, I would suggest just getting rid of "Option 1" altogether.
    It
    would end up over-complicating this to such a degree that any
    usefulness
    it
    might serve would be considerably diminished.

    As for embedded HTML, if you allow the ?>  tag in these .phpp files,
    then
    that pretty much negates the entire purpose of having them to begin
    with.
    Essentially, you'd just be changing it so that, instead of defaulting
    to
    "?>" when no tag is present, it defaults to"<?php".  I just don't see
    any
    value in that as a developer.

    A developer should *not* be including in a .phpp file classes that
    contain
    HTML within the ?>  tag, period.  If they need to include something
    that
    has
    that, they should do it in a regular .php file.  An "HTML-less" PHP
    file
    needs to be exactly that; no direct HTML allowed.  Otherwise, the RFC
    is
    completely and utterly pointless IMHO.


    I think this would be awesome for PHP 6, but I'll have to vote against
    it
    if you settle on using "Option 1" and/or allow ?>  content to be
    embedded/included in .phpp files.  If we differentiate based solely on
    the
    file extension and keep ?>  tags out of it, then I'll definitely
    support
    it!



    Please forget about file extensions.  PHP should not consider file
    extensions.  The only reason .php files are executed by PHP is because
    the
    web browser is configured to pass that extension to PHP rather than
    handle
    it internally.


    I sincerely hope that any suggestion to eliminate the ability to use PHP
    as
    a template engine will be met with a veto by the core developers, or
    maybe
    even another suggestion by the trademark owner of PHP that he will not
    allow
    the PHP name to be used on such a language.








    --
    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
    Hmm yeah I see your point.  Requiring a separate file extension would force
    configuration changes to the webserver.  And since not everybody has access
    to that, it would mean that any projects that contain these files would not
    be able to run on hosts like that.

    Ok you've convinced me on the file extension issue, just based on that.  But
    I still don't like the new require_* keywords or allowing ?> to be mixed-in
    with PHP scripts that are supposed to be pure code.  Again it just comes
    down to a question of usefulness and creating a solution in search of a
    problem.

    What we need is a way to tell the parser that this file is pure PHP.  We
    can't use the file extension, so it has to be at the code level.  If I'm
    interpreting your proposals correctly, it looks like your approach would be
    to have the including file make this determination.  Personally, I think we
    should do the opposite; i.e. this should be defined in the PHP file itself.

    Obviously, it would need to be at the top of the PHP file (whitespace
    notwithstanding).  Since we don't want any BC breaks, we at very least need
    it to start with "<?" so that we don't end up parsing anything that wasn't
    mean to be parsed.  So how about we keep it simple and just use a single,
    "<?phpp" at the beginning of the file?  No ?> would be allowed after that.
    Anything before that (in the file itself) would also be ignored and throw a
    warning.

    This sounds like the best approach, given the limitations involved with
    webserver configurations.  I'm still very much against though allowing ?>
    within one of these files (included or otherwise), as it really defeats the
    whole purpose and would just encourage poor architecture without any
    countervailing benefit.

    --Kris


    --
    Tom Boutell
    P'unk Avenue
    215 755 1330
    punkave.com
    window.punkave.com
  • Kris Craig at Apr 9, 2012 at 9:32 pm
    Lol true dat. You convinced me on the file extension, so as far as I can
    tell that just leaves us with the tag itself as the viable approach. =)

    --Kris

    On Mon, Apr 9, 2012 at 2:24 PM, Tom Boutell wrote:

    I'm not sure you're wrong about this, but it's definitely an ironic
    suggestion (:
    On Mon, Apr 9, 2012 at 5:22 PM, Kris Craig wrote:

    On Mon, Apr 9, 2012 at 2:03 PM, Tom Boutell wrote:

    As others explained before the RFC was drafted, file extensions should
    not be directly respected by PHP because environments differ too much.
    Instead a convention, NOT enforced at the code level, would be
    published and encouraged: .phpc for files that start out in PHP mode,
    and .php for files that start out in HTML mode. PHP would NOT enforce
    this, it would just be an encouraged practice in the writing of
    autoloaders and so on. (Note that autoloaders are already concerned
    with file extensions. They have to be in order to transform a class
    name into a filename.)

    The RFC does not call for putting an end to the traditional use of PHP
    for templates at all, that is still the default behavior when parsing
    PHP. There is an entirely separate RFC that calls for that, but that's
    another thread.

    On Mon, Apr 9, 2012 at 4:58 PM, Rick WIdmer <vchkpw@developersdesk.com>
    wrote:
    On 4/9/2012 2:41 PM, Kris Craig wrote:
    Honestly, I would suggest just getting rid of "Option 1" altogether.
    It
    would end up over-complicating this to such a degree that any
    usefulness
    it
    might serve would be considerably diminished.

    As for embedded HTML, if you allow the ?> tag in these .phpp files,
    then
    that pretty much negates the entire purpose of having them to begin
    with.
    Essentially, you'd just be changing it so that, instead of defaulting
    to
    "?>" when no tag is present, it defaults to"<?php". I just don't see
    any
    value in that as a developer.

    A developer should *not* be including in a .phpp file classes that
    contain
    HTML within the ?> tag, period. If they need to include something
    that
    has
    that, they should do it in a regular .php file. An "HTML-less" PHP
    file
    needs to be exactly that; no direct HTML allowed. Otherwise, the RFC
    is
    completely and utterly pointless IMHO.


    I think this would be awesome for PHP 6, but I'll have to vote
    against
    it
    if you settle on using "Option 1" and/or allow ?> content to be
    embedded/included in .phpp files. If we differentiate based solely
    on
    the
    file extension and keep ?> tags out of it, then I'll definitely
    support
    it!



    Please forget about file extensions. PHP should not consider file
    extensions. The only reason .php files are executed by PHP is because
    the
    web browser is configured to pass that extension to PHP rather than
    handle
    it internally.


    I sincerely hope that any suggestion to eliminate the ability to use
    PHP
    as
    a template engine will be met with a veto by the core developers, or
    maybe
    even another suggestion by the trademark owner of PHP that he will not
    allow
    the PHP name to be used on such a language.








    --
    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
    Hmm yeah I see your point. Requiring a separate file extension would force
    configuration changes to the webserver. And since not everybody has access
    to that, it would mean that any projects that contain these files would not
    be able to run on hosts like that.

    Ok you've convinced me on the file extension issue, just based on that. But
    I still don't like the new require_* keywords or allowing ?> to be mixed-in
    with PHP scripts that are supposed to be pure code. Again it just comes
    down to a question of usefulness and creating a solution in search of a
    problem.

    What we need is a way to tell the parser that this file is pure PHP. We
    can't use the file extension, so it has to be at the code level. If I'm
    interpreting your proposals correctly, it looks like your approach would be
    to have the including file make this determination. Personally, I think we
    should do the opposite; i.e. this should be defined in the PHP file itself.
    Obviously, it would need to be at the top of the PHP file (whitespace
    notwithstanding). Since we don't want any BC breaks, we at very least need
    it to start with "<?" so that we don't end up parsing anything that wasn't
    mean to be parsed. So how about we keep it simple and just use a single,
    "<?phpp" at the beginning of the file? No ?> would be allowed after that.
    Anything before that (in the file itself) would also be ignored and throw a
    warning.

    This sounds like the best approach, given the limitations involved with
    webserver configurations. I'm still very much against though allowing ?>
    within one of these files (included or otherwise), as it really defeats the
    whole purpose and would just encourage poor architecture without any
    countervailing benefit.

    --Kris


    --
    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 at Apr 9, 2012 at 9:38 pm

    Obviously, it would need to be at the top of the PHP file (whitespace
    notwithstanding). Since we don't want any BC breaks, we at very least need
    it to start with "<?" so that we don't end up parsing anything that wasn't
    mean to be parsed. So how about we keep it simple and just use a single,
    "<?phpp" at the beginning of the file? No ?> would be allowed after that.
    Anything before that (in the file itself) would also be ignored and throw a
    warning.
    Remember, <?xml tags. I think <? By itself was deprecated for this reason.
    This sounds like the best approach, given the limitations involved with
    webserver configurations. I'm still very much against though allowing ?>
    within one of these files (included or otherwise), as it really defeats the
    whole purpose and would just encourage poor architecture without any
    countervailing benefit.
    Agreed. Disallowing ?> in a file in pure code means only one <?php tag
    at the top.

    A flag on require/include is acceptable to me, as long as the default
    mode is configurable in the php.ini file (when none are specified).

    Luke
    --Kris
  • Kris Craig at Apr 9, 2012 at 10:06 pm

    On Mon, Apr 9, 2012 at 2:38 PM, Luke Scott wrote:

    Obviously, it would need to be at the top of the PHP file (whitespace
    notwithstanding). Since we don't want any BC breaks, we at very least need
    it to start with "<?" so that we don't end up parsing anything that wasn't
    mean to be parsed. So how about we keep it simple and just use a single,
    "<?phpp" at the beginning of the file? No ?> would be allowed after that.
    Anything before that (in the file itself) would also be ignored and throw a
    warning.
    Remember, <?xml tags. I think <? By itself was deprecated for this reason.
    Bah, right! That damned <?xml tag....

    I already know what everyone's reaction will be, and it is probably a
    REALLY bad idea, but I feel obligated to at least mention it: Should we
    consider replacing "<?..." with something that doesn't conflict with
    anything, perhaps starting in PHP 6? No need to get out the torches and
    pitchforks, everyone! As insane and problematic as that would be (i.e. BC
    break with roughly 1/3 of the internet lol), I felt as though the subject
    should at least be broached. ;P

    This sounds like the best approach, given the limitations involved with
    webserver configurations. I'm still very much against though allowing ?>
    within one of these files (included or otherwise), as it really defeats the
    whole purpose and would just encourage poor architecture without any
    countervailing benefit.
    Agreed. Disallowing ?> in a file in pure code means only one <?php tag
    at the top.
    A flag on require/include is acceptable to me, as long as the default
    mode is configurable in the php.ini file (when none are specified).
    Perhaps we should split that into a separate RFC? I.e. a require flag that
    tells it to parse the included PHP file as pure PHP, regardless of whether
    or not it has the <?phpp tag. I'm not sure if this would be
    workable/necessary or not, but it's different enough that I think splitting
    it off into a separate proposal would probably make the most sense.

    Luke
    --Kris
  • Tom Boutell at Apr 9, 2012 at 10:17 pm
    My original goal was to stop typing <?php in pure code files. That
    includes at the top. I think it's entirely reasonable to achieve it
    with an option to the require keywords for this purpose and a naming
    convention to be followed by autoloaders. Keep in mind how rarely you
    have to change them. We're talking about code maintained by a
    relatively small number of very sharp developers. They can handle a
    few flags (:

    The prohibition of ?> still seems unnecessary and perhaps divisive,
    but if it were preferable to the majority to prohibit ?> in a pure
    code file, I could live with that as long as classic PHP files are
    also 100% supported and remain the default. I'm trying to craft a
    broadly acceptable compromise that still achieves the original goal of
    allowing people to write "just code" in a class file.
    On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig wrote:

    On Mon, Apr 9, 2012 at 2:38 PM, Luke Scott wrote:

    Obviously, it would need to be at the top of the PHP file (whitespace
    notwithstanding).  Since we don't want any BC breaks, we at very least
    need
    it to start with "<?" so that we don't end up parsing anything that
    wasn't
    mean to be parsed.  So how about we keep it simple and just use a
    single,
    "<?phpp" at the beginning of the file?  No ?> would be allowed after
    that.
    Anything before that (in the file itself) would also be ignored and
    throw a
    warning.
    Remember, <?xml tags. I think <? By itself was deprecated for this reason.

    Bah, right!  That damned <?xml tag....

    I already know what everyone's reaction will be, and it is probably a REALLY
    bad idea, but I feel obligated to at least mention it:  Should we consider
    replacing "<?..." with something that doesn't conflict with anything,
    perhaps starting in PHP 6?  No need to get out the torches and pitchforks,
    everyone!  As insane and problematic as that would be (i.e. BC break with
    roughly 1/3 of the internet lol), I felt as though the subject should at
    least be broached.  ;P
    This sounds like the best approach, given the limitations involved with
    webserver configurations.  I'm still very much against though allowing
    ?>
    within one of these files (included or otherwise), as it really defeats
    the
    whole purpose and would just encourage poor architecture without any
    countervailing benefit.
    Agreed. Disallowing ?> in a file in pure code means only one <?php tag
    at the top.


    A flag on require/include is acceptable to me, as long as the default
    mode is configurable in the php.ini file (when none are specified).

    Perhaps we should split that into a separate RFC?  I.e. a require flag that
    tells it to parse the included PHP file as pure PHP, regardless of whether
    or not it has the <?phpp tag.  I'm not sure if this would be
    workable/necessary or not, but it's different enough that I think splitting
    it off into a separate proposal would probably make the most sense.

    Luke
    --Kris


    --
    Tom Boutell
    P'unk Avenue
    215 755 1330
    punkave.com
    window.punkave.com
  • Luke Scott at Apr 9, 2012 at 10:33 pm
    Tom,
    On 4/9/12 3:17 PM, "Tom Boutell" wrote:

    My original goal was to stop typing <?php in pure code files. That
    includes at the top. I think it's entirely reasonable to achieve it
    with an option to the require keywords for this purpose and a naming
    convention to be followed by autoloaders. Keep in mind how rarely you
    have to change them. We're talking about code maintained by a
    relatively small number of very sharp developers. They can handle a
    few flags (:

    The prohibition of ?> still seems unnecessary and perhaps divisive,
    but if it were preferable to the majority to prohibit ?> in a pure
    code file, I could live with that as long as classic PHP files are
    also 100% supported and remain the default. I'm trying to craft a
    broadly acceptable compromise that still achieves the original goal of
    allowing people to write "just code" in a class file.

    I think you can you achieve that by making "template mode" default and the
    default changeable in the php.ini file.

    Something like this:

    /*
    Code only, <?php at top optional, no ?>.
    Text before opening <?php silently dropped

    */

    require "/path/to/somefile.php", INCLUDE_CODE;

    /*
    Works exactly as it is now: <?php and ?> allowed.
    Text betweeen ?>...<?php printed to output buffer.
    */



    require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now

    /*
    By default INCLUDE_TEMPLATE
    Can change default mode in php.ini to be INCLUDE_CODE if desired.
    */

    require "/path/to/anotherfile.php"; // As it is now


    Personally I would like to be able to do something like this in my auto
    loader:

    include $file, INCLUDE_CODE & INCLUDE_SILENT;



    That way I can ensure pure code is being inserted and no warnings are
    thrown if the file doesn't exist (class undefined will be thrown anyway).

    I think it's important to make <?php optional at the top if you're using
    existing or third party libraries that you can't modify. At least then
    you'll be able to maintain backwards compatibility with most code written
    since PHP 5.

    (We don't need PHP_*. See the output of get_defined_constants() ).

    I like where this is going! Hopefully after the RFC has been finalized
    everyone else will agree.

    On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig wrote:

    Kris,



    Bah, right! That damned <?xml tag....

    I already know what everyone's reaction will be, and it is probably a
    REALLY
    bad idea, but I feel obligated to at least mention it: Should we
    consider
    replacing "<?..." with something that doesn't conflict with anything,
    perhaps starting in PHP 6? No need to get out the torches and
    pitchforks,
    everyone! As insane and problematic as that would be (i.e. BC break
    with
    roughly 1/3 of the internet lol), I felt as though the subject should at
    least be broached. ;P

    No need. Just keep it as <?php. It's already been well established. We
    should ovoid overcomplicating it.

    Luke
  • Tom Boutell at Apr 9, 2012 at 10:53 pm
    I see why you want to allow <?php at the top to be optional in 'code
    mode,' rather than disallowed in code mode. But your purpose is to
    allow legacy code to be autoloaded without knowing in advance whether
    it starts with <?php or not.

    But that would probably lead in practice to the use of a single file
    extension for old and new class files.

    And that, in turn, would lead to source code being spewed to the
    browser for all to see if a perfectly respectable autoloader circa PHP
    5.3 runs into one of these new files.

    This is a much more significant security issue than some of those
    mentioned previously because perfectly well-written code would display
    this behavior if someone unknowingly drops a newer library into, say,
    the lib/ folder of a Symfony 1.4 project. Ouch.

    It would be much better for that autoloader to just ignore the file
    because it has a new extension. This way the problem is immediately
    apparent:

    "Hey, my class didn't load, something must be up. Oh my PHP is old
    and/or this autoloader doesn't know about .phpc files, what are they
    anyway... google google... aha, I need PHP 5.x and an updated
    autoloader. Grumble. Okay."

    This is a much safer outcome.
    On Mon, Apr 9, 2012 at 6:34 PM, Luke Scott wrote:
    Tom,
    On 4/9/12 3:17 PM, "Tom Boutell" wrote:

    My original goal was to stop typing <?php in pure code files. That
    includes at the top. I think it's entirely reasonable to achieve it
    with an option to the require keywords for this purpose and a naming
    convention to be followed by autoloaders. Keep in mind how rarely you
    have to change them. We're talking about code maintained by a
    relatively small number of very sharp developers. They can handle a
    few flags (:

    The prohibition of ?> still seems unnecessary and perhaps divisive,
    but if it were preferable to the majority to prohibit ?> in a pure
    code file, I could live with that as long as classic PHP files are
    also 100% supported and remain the default. I'm trying to craft a
    broadly acceptable compromise that still achieves the original goal of
    allowing people to write "just code" in a class file.

    I think you can you achieve that by making "template mode" default and the
    default changeable in the php.ini file.

    Something like this:

    /*
    Code only, <?php at top optional, no ?>.
    Text before opening <?php silently dropped

    */

    require "/path/to/somefile.php", INCLUDE_CODE;

    /*
    Works exactly as it is now: <?php and ?> allowed.
    Text betweeen ?>...<?php printed to output buffer.
    */



    require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now

    /*
    By default INCLUDE_TEMPLATE
    Can change default mode in php.ini to be INCLUDE_CODE if desired.
    */

    require "/path/to/anotherfile.php"; // As it is now


    Personally I would like to be able to do something like this in my auto
    loader:

    include $file, INCLUDE_CODE & INCLUDE_SILENT;



    That way I can ensure pure code is being inserted and no warnings are
    thrown if the file doesn't exist (class undefined will be thrown anyway).

    I think it's important to make <?php optional at the top if you're using
    existing or third party libraries that you can't modify. At least then
    you'll be able to maintain backwards compatibility with most code written
    since PHP 5.

    (We don't need PHP_*. See the output of get_defined_constants() ).

    I like where this is going! Hopefully after the RFC has been finalized
    everyone else will agree.

    On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig wrote:

    Kris,



    Bah, right!  That damned <?xml tag....

    I already know what everyone's reaction will be, and it is probably a
    REALLY
    bad idea, but I feel obligated to at least mention it:  Should we
    consider
    replacing "<?..." with something that doesn't conflict with anything,
    perhaps starting in PHP 6?  No need to get out the torches and
    pitchforks,
    everyone!  As insane and problematic as that would be (i.e. BC break
    with
    roughly 1/3 of the internet lol), I felt as though the subject should at
    least be broached.  ;P

    No need. Just keep it as <?php. It's already been well established. We
    should ovoid overcomplicating it.

    Luke


    --
    Tom Boutell
    P'unk Avenue
    215 755 1330
    punkave.com
    window.punkave.com
  • Luke Scott at Apr 9, 2012 at 11:04 pm

    On 4/9/12 3:53 PM, "Tom Boutell" wrote:
    I see why you want to allow <?php at the top to be optional in 'code
    mode,' rather than disallowed in code mode. But your purpose is to
    allow legacy code to be autoloaded without knowing in advance whether
    it starts with <?php or not.

    But that would probably lead in practice to the use of a single file
    extension for old and new class files.

    And that, in turn, would lead to source code being spewed to the
    browser for all to see if a perfectly respectable autoloader circa PHP
    5.3 runs into one of these new files.

    This is a much more significant security issue than some of those
    mentioned previously because perfectly well-written code would display
    this behavior if someone unknowingly drops a newer library into, say,
    the lib/ folder of a Symfony 1.4 project. Ouch.

    So are you saying the starting "<?php" tag should be required in "code
    mode"?

    If so, I'm ok with that as long as:

    - "?>" is forbidden

    - Text before the opening <?php tag (literal text or white-spaces) is
    either ignored or throws an error instead of printing to the output buffer.

    If that's not what you mean, please clarify.

    Luke
    It would be much better for that autoloader to just ignore the file
    because it has a new extension. This way the problem is immediately
    apparent:

    "Hey, my class didn't load, something must be up. Oh my PHP is old
    and/or this autoloader doesn't know about .phpc files, what are they
    anyway... google google... aha, I need PHP 5.x and an updated
    autoloader. Grumble. Okay."

    This is a much safer outcome.
    On Mon, Apr 9, 2012 at 6:34 PM, Luke Scott wrote:
    Tom,
    On 4/9/12 3:17 PM, "Tom Boutell" wrote:

    My original goal was to stop typing <?php in pure code files. That
    includes at the top. I think it's entirely reasonable to achieve it
    with an option to the require keywords for this purpose and a naming
    convention to be followed by autoloaders. Keep in mind how rarely you
    have to change them. We're talking about code maintained by a
    relatively small number of very sharp developers. They can handle a
    few flags (:

    The prohibition of ?> still seems unnecessary and perhaps divisive,
    but if it were preferable to the majority to prohibit ?> in a pure
    code file, I could live with that as long as classic PHP files are
    also 100% supported and remain the default. I'm trying to craft a
    broadly acceptable compromise that still achieves the original goal of
    allowing people to write "just code" in a class file.

    I think you can you achieve that by making "template mode" default and
    the
    default changeable in the php.ini file.

    Something like this:

    /*
    Code only, <?php at top optional, no ?>.
    Text before opening <?php silently dropped

    */

    require "/path/to/somefile.php", INCLUDE_CODE;

    /*
    Works exactly as it is now: <?php and ?> allowed.
    Text betweeen ?>...<?php printed to output buffer.
    */



    require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now

    /*
    By default INCLUDE_TEMPLATE
    Can change default mode in php.ini to be INCLUDE_CODE if desired.
    */

    require "/path/to/anotherfile.php"; // As it is now


    Personally I would like to be able to do something like this in my auto
    loader:

    include $file, INCLUDE_CODE & INCLUDE_SILENT;



    That way I can ensure pure code is being inserted and no warnings are
    thrown if the file doesn't exist (class undefined will be thrown
    anyway).

    I think it's important to make <?php optional at the top if you're using
    existing or third party libraries that you can't modify. At least then
    you'll be able to maintain backwards compatibility with most code
    written
    since PHP 5.

    (We don't need PHP_*. See the output of get_defined_constants() ).

    I like where this is going! Hopefully after the RFC has been finalized
    everyone else will agree.

    On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig wrote:

    Kris,



    Bah, right! That damned <?xml tag....

    I already know what everyone's reaction will be, and it is probably a
    REALLY
    bad idea, but I feel obligated to at least mention it: Should we
    consider
    replacing "<?..." with something that doesn't conflict with anything,
    perhaps starting in PHP 6? No need to get out the torches and
    pitchforks,
    everyone! As insane and problematic as that would be (i.e. BC break
    with
    roughly 1/3 of the internet lol), I felt as though the subject should
    at
    least be broached. ;P

    No need. Just keep it as <?php. It's already been well established. We
    should ovoid overcomplicating it.

    Luke


    --
    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 at Apr 9, 2012 at 11:47 pm
    Let me be very clear about that... I am NOT proposing that <?php at
    the top be mandatory in a file loaded in code mode! I don't want to
    type it ever again outside of a template file, personally. See the
    title of the RFC.
    On Mon, Apr 9, 2012 at 7:06 PM, Luke Scott wrote:
    On 4/9/12 3:53 PM, "Tom Boutell" wrote:

    I see why you want to allow <?php at the top to be optional in 'code
    mode,' rather than disallowed in code mode. But your purpose is to
    allow legacy code to be autoloaded without knowing in advance whether
    it starts with <?php or not.

    But that would probably lead in practice to the use of a single file
    extension for old and new class files.

    And that, in turn, would lead to source code being spewed to the
    browser for all to see if a perfectly respectable autoloader circa PHP
    5.3 runs into one of these new files.

    This is a much more significant security issue than some of those
    mentioned previously because perfectly well-written code would display
    this behavior if someone unknowingly drops a newer library into, say,
    the lib/ folder of a Symfony 1.4 project. Ouch.

    So are you saying the starting "<?php" tag should be required in "code
    mode"?

    If so, I'm ok with that as long as:

    - "?>" is forbidden

    - Text before the opening <?php tag (literal text or white-spaces) is
    either ignored or throws an error instead of printing to the output buffer.

    If that's not what you mean, please clarify.

    Luke
    It would be much better for that autoloader to just ignore the file
    because it has a new extension. This way the problem is immediately
    apparent:

    "Hey, my class didn't load, something must be up. Oh my PHP is old
    and/or this autoloader doesn't know about .phpc files, what are they
    anyway... google google... aha, I need PHP 5.x and an updated
    autoloader. Grumble. Okay."

    This is a much safer outcome.
    On Mon, Apr 9, 2012 at 6:34 PM, Luke Scott wrote:
    Tom,
    On 4/9/12 3:17 PM, "Tom Boutell" wrote:

    My original goal was to stop typing <?php in pure code files. That
    includes at the top. I think it's entirely reasonable to achieve it
    with an option to the require keywords for this purpose and a naming
    convention to be followed by autoloaders. Keep in mind how rarely you
    have to change them. We're talking about code maintained by a
    relatively small number of very sharp developers. They can handle a
    few flags (:

    The prohibition of ?> still seems unnecessary and perhaps divisive,
    but if it were preferable to the majority to prohibit ?> in a pure
    code file, I could live with that as long as classic PHP files are
    also 100% supported and remain the default. I'm trying to craft a
    broadly acceptable compromise that still achieves the original goal of
    allowing people to write "just code" in a class file.

    I think you can you achieve that by making "template mode" default and
    the
    default changeable in the php.ini file.

    Something like this:

    /*
    Code only, <?php at top optional, no ?>.
    Text before opening <?php silently dropped

    */

    require "/path/to/somefile.php", INCLUDE_CODE;

    /*
    Works exactly as it is now: <?php and ?> allowed.
    Text betweeen ?>...<?php printed to output buffer.
    */



    require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now

    /*
    By default INCLUDE_TEMPLATE
    Can change default mode in php.ini to be INCLUDE_CODE if desired.
    */

    require "/path/to/anotherfile.php"; // As it is now


    Personally I would like to be able to do something like this in my auto
    loader:

    include $file, INCLUDE_CODE & INCLUDE_SILENT;



    That way I can ensure pure code is being inserted and no warnings are
    thrown if the file doesn't exist (class undefined will be thrown
    anyway).

    I think it's important to make <?php optional at the top if you're using
    existing or third party libraries that you can't modify. At least then
    you'll be able to maintain backwards compatibility with most code
    written
    since PHP 5.

    (We don't need PHP_*. See the output of get_defined_constants() ).

    I like where this is going! Hopefully after the RFC has been finalized
    everyone else will agree.

    On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig wrote:

    Kris,



    Bah, right!  That damned <?xml tag....

    I already know what everyone's reaction will be, and it is probably a
    REALLY
    bad idea, but I feel obligated to at least mention it:  Should we
    consider
    replacing "<?..." with something that doesn't conflict with anything,
    perhaps starting in PHP 6?  No need to get out the torches and
    pitchforks,
    everyone!  As insane and problematic as that would be (i.e. BC break
    with
    roughly 1/3 of the internet lol), I felt as though the subject should
    at
    least be broached.  ;P

    No need. Just keep it as <?php. It's already been well established. We
    should ovoid overcomplicating it.

    Luke


    --
    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
  • Kris Craig at Apr 10, 2012 at 12:02 am

    On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell wrote:

    Let me be very clear about that... I am NOT proposing that <?php at
    the top be mandatory in a file loaded in code mode! I don't want to
    type it ever again outside of a template file, personally. See the
    title of the RFC.
    But again, how then do you intend to make it so that a pure-code file can
    be called directly from the webserver on a host where the developer doesn't
    have access to most config options? This is a very common scenario that
    cannot be ignored. If not a <?phpp tag, then *something* in that file has
    to identify it as pure code otherwise this just isn't workable.

    Any INI option would be problematic because that would essentially cause
    all scripts relying on the setting you didn't choose to break. And
    unfortunately, recognizing a new file extension could pose problems for
    people running on heavily restricted hosts that currently have PHP support
    "built-in". While I would never host on one of those services myself, I
    don't like the idea of suddenly alienating everyone who does.

    I'd totally be open to an alternative to the <?phpp tag that can withstand
    scrutiny, but so far I haven't seen one. And absent that, there's no way I
    could support this, which really sucks because at least conceptually I
    think it's a really good idea.

    --Kris


    On Mon, Apr 9, 2012 at 7:06 PM, Luke Scott wrote:
    On 4/9/12 3:53 PM, "Tom Boutell" wrote:

    I see why you want to allow <?php at the top to be optional in 'code
    mode,' rather than disallowed in code mode. But your purpose is to
    allow legacy code to be autoloaded without knowing in advance whether
    it starts with <?php or not.

    But that would probably lead in practice to the use of a single file
    extension for old and new class files.

    And that, in turn, would lead to source code being spewed to the
    browser for all to see if a perfectly respectable autoloader circa PHP
    5.3 runs into one of these new files.

    This is a much more significant security issue than some of those
    mentioned previously because perfectly well-written code would display
    this behavior if someone unknowingly drops a newer library into, say,
    the lib/ folder of a Symfony 1.4 project. Ouch.

    So are you saying the starting "<?php" tag should be required in "code
    mode"?

    If so, I'm ok with that as long as:

    - "?>" is forbidden

    - Text before the opening <?php tag (literal text or white-spaces) is
    either ignored or throws an error instead of printing to the output buffer.
    If that's not what you mean, please clarify.

    Luke
    It would be much better for that autoloader to just ignore the file
    because it has a new extension. This way the problem is immediately
    apparent:

    "Hey, my class didn't load, something must be up. Oh my PHP is old
    and/or this autoloader doesn't know about .phpc files, what are they
    anyway... google google... aha, I need PHP 5.x and an updated
    autoloader. Grumble. Okay."

    This is a much safer outcome.
    On Mon, Apr 9, 2012 at 6:34 PM, Luke Scott wrote:
    Tom,
    On 4/9/12 3:17 PM, "Tom Boutell" wrote:

    My original goal was to stop typing <?php in pure code files. That
    includes at the top. I think it's entirely reasonable to achieve it
    with an option to the require keywords for this purpose and a naming
    convention to be followed by autoloaders. Keep in mind how rarely you
    have to change them. We're talking about code maintained by a
    relatively small number of very sharp developers. They can handle a
    few flags (:

    The prohibition of ?> still seems unnecessary and perhaps divisive,
    but if it were preferable to the majority to prohibit ?> in a pure
    code file, I could live with that as long as classic PHP files are
    also 100% supported and remain the default. I'm trying to craft a
    broadly acceptable compromise that still achieves the original goal of
    allowing people to write "just code" in a class file.

    I think you can you achieve that by making "template mode" default and
    the
    default changeable in the php.ini file.

    Something like this:

    /*
    Code only, <?php at top optional, no ?>.
    Text before opening <?php silently dropped

    */

    require "/path/to/somefile.php", INCLUDE_CODE;

    /*
    Works exactly as it is now: <?php and ?> allowed.
    Text betweeen ?>...<?php printed to output buffer.
    */



    require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now

    /*
    By default INCLUDE_TEMPLATE
    Can change default mode in php.ini to be INCLUDE_CODE if desired.
    */

    require "/path/to/anotherfile.php"; // As it is now


    Personally I would like to be able to do something like this in my auto
    loader:

    include $file, INCLUDE_CODE & INCLUDE_SILENT;



    That way I can ensure pure code is being inserted and no warnings are
    thrown if the file doesn't exist (class undefined will be thrown
    anyway).

    I think it's important to make <?php optional at the top if you're
    using
    existing or third party libraries that you can't modify. At least then
    you'll be able to maintain backwards compatibility with most code
    written
    since PHP 5.

    (We don't need PHP_*. See the output of get_defined_constants() ).

    I like where this is going! Hopefully after the RFC has been finalized
    everyone else will agree.

    On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig wrote:

    Kris,



    Bah, right! That damned <?xml tag....

    I already know what everyone's reaction will be, and it is probably a
    REALLY
    bad idea, but I feel obligated to at least mention it: Should we
    consider
    replacing "<?..." with something that doesn't conflict with anything,
    perhaps starting in PHP 6? No need to get out the torches and
    pitchforks,
    everyone! As insane and problematic as that would be (i.e. BC break
    with
    roughly 1/3 of the internet lol), I felt as though the subject should
    at
    least be broached. ;P

    No need. Just keep it as <?php. It's already been well established. We
    should ovoid overcomplicating it.

    Luke


    --
    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

Related Discussions