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