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 <l...@cywh.com> wrote:
> On Apr 9, 2012, at 10:44 AM, Ralph Schindler <ra...@ralphschindler.com> wrote:
>
>> Hey Tom,
>>
>> An idea, why not overload require/include with a second parameter that
>> simply enforces an include mode. For example
>>
>> // in some autoloader (include, requires, and *_onces)
>> include $pathToFile, INCLUDE_MODE_PHP_ONLY;
>>
>> This would tell the parser/executor to start in PHP mode and never leave it,
>> that way, ending tags would throw a runtime/execution error.
>>
>> Other constants and behaviors could be:
>>
>> INCLUDE_MODE_PHP_START;
>> INCLUDE_MODE_PASSTRHOUGH_START; (the current and default behavior)
>>
>> This would have the least amount of impact on BC, and seeminlyg would be a
>> friendly change to the lexer/syntax.
>>
>> Thoughts?
>
>
> If this were to happen:
>
> - I would prefer much shorter elegant constants.
>
> - A constant for suppressing warnings thrown by include without
> suppressing warnings/errors by the actual file -- I think we can all
> agree @include is counter productive since it does much more that
> suppress warnings thrown by include (even parse errors!).
>
> Luke
>
>
>>
>> -ralph
>>
>>
>>
>> On 4/9/12 12:23 PM, Tom Boutell wrote:
>>> Also, your objection - that 'require_code' is confusing - would most
>>> likely be an issue for a handful of people who write autoloaders.
>>> Those clean PHP class files are almost always autoloaded.
>>>
>>> On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell<t...@punkave.com> 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<l...@cywh.com> wrote:
>>>>> On Apr 9, 2012, at 9:16 AM, Tom Boutell<t...@punkave.com> 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<l...@cywh.com> 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<t...@punkave.com> wrote:
>>>>>>>
>>>>>>>> I have written an RFC proposing backwards-compatible support for
>>>>>>>> source files without an opening<?php tag:
>>>>>>>>
>>>>>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>>>>>>
>>>>>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>>>>>>>> what the requirements are to get it added to the "Under Discussion"
>>>>>>>> session and get the ball rolling formally. Please enlighten and I'll
>>>>>>>> do whatever is required.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> --
>>>>>>>> Tom Boutell
>>>>>>>> P'unk Avenue
>>>>>>>> 215 755 1330
>>>>>>>> punkave.com
>>>>>>>> window.punkave.com
>>>>>>>>
>>>>>>>> --
>>>>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Tom Boutell
>>>>>> P'unk Avenue
>>>>>> 215 755 1330
>>>>>> punkave.com
>>>>>> window.punkave.com
>>>>>>
>>>>>> --
>>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Tom Boutell
>>>> P'unk Avenue
>>>> 215 755 1330
>>>> punkave.com
>>>> window.punkave.com
>>>
>>>
>>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
