Go for votes for the open tag-less PHP files

13 years ago by Pierre Joye — view source — reply

unread

hi!

Without willing to end discussions prematurely, it looks to me that
everything possible have been said about the various opening tags
proposals. For one, I do not follow any of these discussions anymore.
And I suppose I am not the only one.

I would strongly suggest to move to the actual proposal phase and go
for the voting phase. To do that, please try to merge the the three
RFCs if possible to ease the voting process.

ps: this is not a new thread to discuss this topic, so simply do
whatever is necessary to move to the next phase, thanks :)

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Kris Craig — view source — reply

unread

hi!

Without willing to end discussions prematurely, it looks to me that
everything possible have been said about the various opening tags
proposals.

Actually, we finally appear to be making some headway. I appreciate your
concerns, but my RFC certainly is nowhere near ready to be voted on, and
last time I checked the other two weren't, either. I don't want to spam
the inboxes of people who aren't interested, but we do need to discuss this
further before anything can move forward. I'm open to ideas on how we can
accomplish both. Perhaps a new list for RFC-specific discussions? =)

--Kris

For one, I do not follow any of these discussions anymore.
And I suppose I am not the only one.

I would strongly suggest to move to the actual proposal phase and go
for the voting phase. To do that, please try to merge the the three
RFCs if possible to ease the voting process.

ps: this is not a new thread to discuss this topic, so simply do
whatever is necessary to move to the next phase, thanks :)

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Pierre Joye — view source — reply

unread

hi,

Perhaps a new list for RFC-specific discussions? =)

We don't need yet a new list. Sit down together and get over your
differences and create the RFC or more if you can't get over your
differences.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Tom Boutell — view source — reply

unread

I don't think a consensus on the following points is likely to emerge
without voting on them individually. I propose carrying out a vote
with up to three questions to be answered depending on your response
to each. We could then proceed to discuss the (relatively boring but
essential) details of keywords and extensions, if any, and create a
final RFC.

Hopefully all parties can agree to be bound by the results of a vote
on these three questions and work together to create a final RFC that
abides by the result or let the matter drop.

Let's briefly discuss whether these questions truly represent the
major differences between the three RFCs (not the merits of those
positions please) and then, I hope, carry out a vote on them so we can
move on.

The Questions:

Whether a "pure code" mode in which <?php is not required at the
top of a file, and the <?php and ?> tags are not permitted at all in
such a file:

Has merit and should be pursued (option 1a), or
Should be dropped entirely (option 1b).

If your vote is for option 1a, please respond to the following
additional question:

Whether "pure code" mode should be:

Toggled globally by a php.ini option such that <?php and ?> tags are
completely forbidden when this mode is active (option 2a), or
Switched on by keywords and SAPI options that allow the sysadmin and
developer to make the choice at runtime, with the ability to make that
choice differently for different files or invocations, so that a mix
of "pure code" files and files that forbid <?php and ?> can exist
(option 2b).

If your vote is for option 2b, please respond to the following
additional question:

Whether "pure code" mode should:

Forbid requiring a non-pure file from a pure file (option 3a), or
Permit requiring non-pure files from pure files (option 3b).

I believe Kris Craig and Yasuo Ohgaki will find that these questions
accurately sum up our really significant unreconciled differences
(and, with the inclusion of question 1, the position of those who
don't want the feature at all).

These three questions deliberately don't address what the keywords or
file extensions or other mechanisms are called exactly, because I
believe those issues to be fairly simple to agree upon once we have
decided the basics.

hi,

Perhaps a new list for RFC-specific discussions? =)

We don't need yet a new list. Sit down together and get over your
differences and create the RFC or more if you can't get over your
differences.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--

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

13 years ago by Kris Craig — view source — reply

unread

I don't think a consensus on the following points is likely to emerge
without voting on them individually. I propose carrying out a vote
with up to three questions to be answered depending on your response
to each. We could then proceed to discuss the (relatively boring but
essential) details of keywords and extensions, if any, and create a
final RFC.

Hopefully all parties can agree to be bound by the results of a vote
on these three questions and work together to create a final RFC that
abides by the result or let the matter drop.

Let's briefly discuss whether these questions truly represent the
major differences between the three RFCs (not the merits of those
positions please) and then, I hope, carry out a vote on them so we can
move on.

The Questions:

Whether a "pure code" mode in which <?php is not required at the
top of a file, and the <?php and ?> tags are not permitted at all in
such a file:

Has merit and should be pursued (option 1a), or

Should be dropped entirely (option 1b).

If your vote is for option 1a, please respond to the following
additional question:

Whether "pure code" mode should be:

Toggled globally by a php.ini option such that <?php and ?> tags are
completely forbidden when this mode is active (option 2a), or

Switched on by keywords and SAPI options that allow the sysadmin and
developer to make the choice at runtime, with the ability to make that
choice differently for different files or invocations, so that a mix
of "pure code" files and files that forbid <?php and ?> can exist
(option 2b).

If your vote is for option 2b, please respond to the following
additional question:

Whether "pure code" mode should:

Forbid requiring a non-pure file from a pure file (option 3a), or

Permit requiring non-pure files from pure files (option 3b).

Question 3 may not be necessary given a possible new parallel approach
being discussed. Please refer to my RFCs thread for details and to weigh
in on that.

I believe Kris Craig and Yasuo Ohgaki will find that these questions
accurately sum up our really significant unreconciled differences
(and, with the inclusion of question 1, the position of those who
don't want the feature at all).

These three questions deliberately don't address what the keywords or
file extensions or other mechanisms are called exactly, because I
believe those issues to be fairly simple to agree upon once we have
decided the basics.

Overall, I like the idea, but I think it's premature. For my part, I still
need more time to brainstorm and discuss. Keep in mind that my RFC was
only drafted a few days ago and the RFC process requires a minimum of 2
weeks before a vote can be held. I'd prefer to adhere to that rule for the
time being. I see no benefit in rushing things. I ask that everybody come
back to the table and spend some more time trying to establish where we
share common ground. I can't support a vote, at least on my RFC, at this
time.

hi,

On Sun, Apr 15, 2012 at 1:00 PM, Kris Craig kris.craig@gmail.com
wrote:

Perhaps a new list for RFC-specific discussions? =)

We don't need yet a new list. Sit down together and get over your
differences and create the RFC or more if you can't get over your
differences.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--

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

13 years ago by Kris Craig — view source — reply

unread

err it might be 1 week, not 2. Either way, it's definitely too soon for
mine to be voted on.

--Kris

I don't think a consensus on the following points is likely to emerge
without voting on them individually. I propose carrying out a vote
with up to three questions to be answered depending on your response
to each. We could then proceed to discuss the (relatively boring but
essential) details of keywords and extensions, if any, and create a
final RFC.

Hopefully all parties can agree to be bound by the results of a vote
on these three questions and work together to create a final RFC that
abides by the result or let the matter drop.

Let's briefly discuss whether these questions truly represent the
major differences between the three RFCs (not the merits of those
positions please) and then, I hope, carry out a vote on them so we can
move on.

The Questions:

Whether a "pure code" mode in which <?php is not required at the
top of a file, and the <?php and ?> tags are not permitted at all in
such a file:

Has merit and should be pursued (option 1a), or

Should be dropped entirely (option 1b).

If your vote is for option 1a, please respond to the following
additional question:

Whether "pure code" mode should be:

Toggled globally by a php.ini option such that <?php and ?> tags are
completely forbidden when this mode is active (option 2a), or

Switched on by keywords and SAPI options that allow the sysadmin and
developer to make the choice at runtime, with the ability to make that
choice differently for different files or invocations, so that a mix
of "pure code" files and files that forbid <?php and ?> can exist
(option 2b).

If your vote is for option 2b, please respond to the following
additional question:

Whether "pure code" mode should:

Forbid requiring a non-pure file from a pure file (option 3a), or

Permit requiring non-pure files from pure files (option 3b).

Question 3 may not be necessary given a possible new parallel approach
being discussed. Please refer to my RFCs thread for details and to weigh
in on that.

I believe Kris Craig and Yasuo Ohgaki will find that these questions
accurately sum up our really significant unreconciled differences
(and, with the inclusion of question 1, the position of those who
don't want the feature at all).

These three questions deliberately don't address what the keywords or
file extensions or other mechanisms are called exactly, because I
believe those issues to be fairly simple to agree upon once we have
decided the basics.

Overall, I like the idea, but I think it's premature. For my part, I
still need more time to brainstorm and discuss. Keep in mind that my RFC
was only drafted a few days ago and the RFC process requires a minimum of
2 weeks before a vote can be held. I'd prefer to adhere to that rule for
the time being. I see no benefit in rushing things. I ask that everybody
come back to the table and spend some more time trying to establish where
we share common ground. I can't support a vote, at least on my RFC, at
this time.

On Sun, Apr 15, 2012 at 7:05 AM, Pierre Joye pierre.php@gmail.com
wrote:

hi,

On Sun, Apr 15, 2012 at 1:00 PM, Kris Craig kris.craig@gmail.com
wrote:

Perhaps a new list for RFC-specific discussions? =)

We don't need yet a new list. Sit down together and get over your
differences and create the RFC or more if you can't get over your
differences.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--

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

13 years ago by Kris Craig — view source — reply

unread

Bah sorry everyone, I just woke up and I'm still a little groggy lol. It
is in fact 2 weeks.

--Kris

err it might be 1 week, not 2. Either way, it's definitely too soon for
mine to be voted on.

--Kris

I don't think a consensus on the following points is likely to emerge
without voting on them individually. I propose carrying out a vote
with up to three questions to be answered depending on your response
to each. We could then proceed to discuss the (relatively boring but
essential) details of keywords and extensions, if any, and create a
final RFC.

Hopefully all parties can agree to be bound by the results of a vote
on these three questions and work together to create a final RFC that
abides by the result or let the matter drop.

Let's briefly discuss whether these questions truly represent the
major differences between the three RFCs (not the merits of those
positions please) and then, I hope, carry out a vote on them so we can
move on.

The Questions:

Whether a "pure code" mode in which <?php is not required at the
top of a file, and the <?php and ?> tags are not permitted at all in
such a file:

Has merit and should be pursued (option 1a), or

Should be dropped entirely (option 1b).

If your vote is for option 1a, please respond to the following
additional question:

Whether "pure code" mode should be:

Toggled globally by a php.ini option such that <?php and ?> tags are
completely forbidden when this mode is active (option 2a), or

Switched on by keywords and SAPI options that allow the sysadmin and
developer to make the choice at runtime, with the ability to make that
choice differently for different files or invocations, so that a mix
of "pure code" files and files that forbid <?php and ?> can exist
(option 2b).

If your vote is for option 2b, please respond to the following
additional question:

Whether "pure code" mode should:

Forbid requiring a non-pure file from a pure file (option 3a), or

Permit requiring non-pure files from pure files (option 3b).

Question 3 may not be necessary given a possible new parallel approach
being discussed. Please refer to my RFCs thread for details and to weigh
in on that.

I believe Kris Craig and Yasuo Ohgaki will find that these questions
accurately sum up our really significant unreconciled differences
(and, with the inclusion of question 1, the position of those who
don't want the feature at all).

These three questions deliberately don't address what the keywords or
file extensions or other mechanisms are called exactly, because I
believe those issues to be fairly simple to agree upon once we have
decided the basics.

Overall, I like the idea, but I think it's premature. For my part, I
still need more time to brainstorm and discuss. Keep in mind that my RFC
was only drafted a few days ago and the RFC process requires a minimum of
2 weeks before a vote can be held. I'd prefer to adhere to that rule for
the time being. I see no benefit in rushing things. I ask that everybody
come back to the table and spend some more time trying to establish where
we share common ground. I can't support a vote, at least on my RFC, at
this time.

On Sun, Apr 15, 2012 at 7:05 AM, Pierre Joye pierre.php@gmail.com
wrote:

hi,

On Sun, Apr 15, 2012 at 1:00 PM, Kris Craig kris.craig@gmail.com
wrote:

Perhaps a new list for RFC-specific discussions? =)

We don't need yet a new list. Sit down together and get over your
differences and create the RFC or more if you can't get over your
differences.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--

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

13 years ago by Pierre Joye — view source — reply

unread

hi Tom,

I don't think a consensus on the following points is likely to emerge
without voting on them individually. I propose carrying out a vote
with up to three questions to be answered depending on your response
to each. We could then proceed to discuss the (relatively boring but
essential) details of keywords and extensions, if any, and create a
final RFC.

Hopefully all parties can agree to be bound by the results of a vote
on these three questions and work together to create a final RFC that
abides by the result or let the matter drop.

Let's briefly discuss whether these questions truly represent the
major differences between the three RFCs (not the merits of those
positions please) and then, I hope, carry out a vote on them so we can
move on.

Agreed on your proposed next steps.

It would rock if you could lead this effort and come up with a RFC
covering the various points. I would suggest to sit down together with
the other RFCs' authors and get that done. But please, no more
discussions here about that. Makes no sense :)

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Yasuo Ohgaki — view source — reply

unread

Hi,

It would be better to vote

PHP will have script only (tag less) code or not

then

How it will be implemented

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

13 years ago by Kris Craig — view source — reply

unread

Hi,

It would be better to vote

PHP will have script only (tag less) code or not

then

How it will be implemented

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Awhile back, I raised the possibility of creating an RFC to expand the RFC
voting process to allow for multiple questions, as well as provide clarity
for cleaning-up "abandoned" RFCs, etc. This seems like exactly the kind of
use case I had in mind. If I took some time this week to write a rough
draft of a new RFC on this, is that something any of you would be
interested in?

--Kris

13 years ago by Arvids Godjuks — view source — reply

unread

What happened with the proposal/RFC for expanding include/require with
additional optional second param to allow for developers to define in place
if he want's a pure PHP file to be included or a template file with direct
HTML output?
I like that proposal and take it over any other, because it gives developer
a choice. And if things do not go the right way and he ends up screwing up
somewhere - he is able to fall back to the old mode just by modifying the
include/require statement (and in a MVC framework with autoload usage that
would be 1-2 places in the whole project).
All that stuff with keywords, removing <?php tags and using special
extensions require a continuous effort from the developers, additional
support from the IDE/editors/other tools. Do we really need all that just
to give people the ability to load their scripts as a pure PHP code?
To my mind a modification to the include/require statements is all there is
required to add that extra thing that Kris want's so badly and does not
require to change your habbits, IDE templates, waiting for IDE/editors/WEB
source code highlight libraries/source analyzers/etc to catch up with the
change.
There is also a question I just raised that is not yet answered that the
keyword/extension thing can just break the valid performance tweak
technique, that is used extensively in any project with big code base.

13 years ago by Kris Craig — view source — reply

unread

Arvids,

On Mon, Apr 16, 2012 at 12:46 AM, Arvids Godjuks
arvids.godjuks@gmail.comwrote:

What happened with the proposal/RFC for expanding include/require with
additional optional second param to allow for developers to define in place
if he want's a pure PHP file to be included or a template file with direct
HTML output?
I like that proposal and take it over any other, because it gives
developer a choice. And if things do not go the right way and he ends up
screwing up somewhere - he is able to fall back to the old mode just by
modifying the include/require statement (and in a MVC framework with
autoload usage that would be 1-2 places in the whole project).
All that stuff with keywords, removing <?php tags and using special
extensions require a continuous effort from the developers, additional
support from the IDE/editors/other tools. Do we really need all that just
to give people the ability to load their scripts as a pure PHP code?
To my mind a modification to the include/require statements is all there
is required to add that extra thing that Kris want's so badly and does not
require to change your habbits, IDE templates, waiting for IDE/editors/WEB
source code highlight libraries/source analyzers/etc to catch up with the
change.
There is also a question I just raised that is not yet answered that the
keyword/extension thing can just break the valid performance tweak
technique, that is used extensively in any project with big code base.

That may very well be the method proposed in my RFC, too. I haven't made
up my mind on that point as I'd like to cover the pros/cons a little more
in depth (including the potential perf issue you just raised). A handler
approach or something similar will still be necessary as well, since one
key reason for my RFC was to make it so that these scripts could be
executed directly via the webserver. But as for determining how PHP itself
can identify a .phpp file, I think the three best options are: Create new
tags, create new keywords, or create new parameters to existing keywords.
I keep bouncing back and forth on which one I think is best, which tells
me that I need to hear more debate on that. Thoughts?

--Kris

13 years ago by Arvids Godjuks — view source — reply

unread

16 апреля 2012 г. 11:05 пользователь Kris Craig kris.craig@gmail.comнаписал:

Arvids,

On Mon, Apr 16, 2012 at 12:46 AM, Arvids Godjuks <arvids.godjuks@gmail.com

wrote:

What happened with the proposal/RFC for expanding include/require with
additional optional second param to allow for developers to define in place
if he want's a pure PHP file to be included or a template file with direct
HTML output?
I like that proposal and take it over any other, because it gives
developer a choice. And if things do not go the right way and he ends up
screwing up somewhere - he is able to fall back to the old mode just by
modifying the include/require statement (and in a MVC framework with
autoload usage that would be 1-2 places in the whole project).
All that stuff with keywords, removing <?php tags and using special
extensions require a continuous effort from the developers, additional
support from the IDE/editors/other tools. Do we really need all that just
to give people the ability to load their scripts as a pure PHP code?
To my mind a modification to the include/require statements is all there
is required to add that extra thing that Kris want's so badly and does not
require to change your habbits, IDE templates, waiting for IDE/editors/WEB
source code highlight libraries/source analyzers/etc to catch up with the
change.
There is also a question I just raised that is not yet answered that the
keyword/extension thing can just break the valid performance tweak
technique, that is used extensively in any project with big code base.

That may very well be the method proposed in my RFC, too. I haven't made
up my mind on that point as I'd like to cover the pros/cons a little more
in depth (including the potential perf issue you just raised). A handler
approach or something similar will still be necessary as well, since one
key reason for my RFC was to make it so that these scripts could be
executed directly via the webserver. But as for determining how PHP itself
can identify a .phpp file, I think the three best options are: Create new
tags, create new keywords, or create new parameters to existing keywords.
I keep bouncing back and forth on which one I think is best, which tells
me that I need to hear more debate on that. Thoughts?

--Kris

I would encourage you to take a deep look into modifying the
include/require statements, because for all the issues popped out with
.pphp and keywords they just don't exist with include/require. And there is
no need to remove the <?php tags in source files - just make sure they
start first thing in the file and there is no ?> at the end and hey (for my
case - my IDE removes all leading and trailing spaces on file save), your
include 'file', PHP_SOURCE_ONLY; works fine, but including a template
fails (as does an image with embedded <?php ?> tags uploaded through a
security hole) .
It's clean (although some BC break would occur, but I think it's minor),
simple and 100% voluntary. Any decently written 3rd party library will work
without any modification (well, removing trailing ?> is a matter of simple
script if required, but I haven't seen people putting ?> in the end for
years).

13 years ago by Tom Boutell — view source — reply

unread

For some this is sufficient, for others (like myself) getting rid of
the initial <?php for pure files is a primary motivation.

On Mon, Apr 16, 2012 at 9:38 AM, Arvids Godjuks
arvids.godjuks@gmail.com wrote:

16 апреля 2012 г. 11:05 пользователь Kris Craig kris.craig@gmail.comнаписал:

Arvids,

On Mon, Apr 16, 2012 at 12:46 AM, Arvids Godjuks <arvids.godjuks@gmail.com

wrote:

What happened with the proposal/RFC for expanding include/require with
additional optional second param to allow for developers to define in place
if he want's a pure PHP file to be included or a template file with direct
HTML output?
I like that proposal and take it over any other, because it gives
developer a choice. And if things do not go the right way and he ends up
screwing up somewhere - he is able to fall back to the old mode just by
modifying the include/require statement (and in a MVC framework with
autoload usage that would be 1-2 places in the whole project).
All that stuff with keywords, removing <?php tags and using special
extensions require a continuous effort from the developers, additional
support from the IDE/editors/other tools. Do we really need all that just
to give people the ability to load their scripts as a pure PHP code?
To my mind a modification to the include/require statements is all there
is required to add that extra thing that Kris want's so badly and does not
require to change your habbits, IDE templates, waiting for IDE/editors/WEB
source code highlight libraries/source analyzers/etc to catch up with the
change.
There is also a question I just raised that is not yet answered that the
keyword/extension thing can just break the valid performance tweak
technique, that is used extensively in any project with big code base.

That may very well be the method proposed in my RFC, too. I haven't made
up my mind on that point as I'd like to cover the pros/cons a little more
in depth (including the potential perf issue you just raised). A handler
approach or something similar will still be necessary as well, since one
key reason for my RFC was to make it so that these scripts could be
executed directly via the webserver. But as for determining how PHP itself
can identify a .phpp file, I think the three best options are: Create new
tags, create new keywords, or create new parameters to existing keywords.
I keep bouncing back and forth on which one I think is best, which tells
me that I need to hear more debate on that. Thoughts?

--Kris

I would encourage you to take a deep look into modifying the
include/require statements, because for all the issues popped out with
.pphp and keywords they just don't exist with include/require. And there is
no need to remove the <?php tags in source files - just make sure they
start first thing in the file and there is no ?> at the end and hey (for my
case - my IDE removes all leading and trailing spaces on file save), your
include 'file', PHP_SOURCE_ONLY; works fine, but including a template
fails (as does an image with embedded <?php ?> tags uploaded through a
security hole) .
It's clean (although some BC break would occur, but I think it's minor),
simple and 100% voluntary. Any decently written 3rd party library will work
without any modification (well, removing trailing ?> is a matter of simple
script if required, but I haven't seen people putting ?> in the end for
years).

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

13 years ago by Ferenc Kovacs — view source — reply

unread

On Mon, Apr 16, 2012 at 9:46 AM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

What happened with the proposal/RFC for expanding include/require with
additional optional second param to allow for developers to define in place
if he want's a pure PHP file to be included or a template file with direct
HTML output?
I like that proposal and take it over any other, because it gives developer
a choice.

there is a valid issue which was discussed on irc yesterday:
because include/require is a language construct, not a method, one is
allowed, even advised to write the include/require calls without putting
out the parentheses.
if we introduce additional arguments for include/require, the following
code will break:
echo include 'foo.bar', 'baz';
as currently it was interpreted as
echo include('foo.bar'), 'baz';
ofc. we could make that the additional params to include, require would
only used, if the parentheses are uses, but that would make require/include
inconsistent with every other language construct, where the parentheses is
optional.
so we either accept this BC, or not pursue this option, but go with the new
functions/opcodes like include_code/require_code or similar.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

13 years ago by Arvids Godjuks — view source — reply

unread

16 апреля 2012 г. 11:24 пользователь Ferenc Kovacs tyra3l@gmail.comнаписал:

On Mon, Apr 16, 2012 at 9:46 AM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

What happened with the proposal/RFC for expanding include/require with
additional optional second param to allow for developers to define in
place
if he want's a pure PHP file to be included or a template file with direct
HTML output?
I like that proposal and take it over any other, because it gives
developer
a choice.

there is a valid issue which was discussed on irc yesterday:
because include/require is a language construct, not a method, one is
allowed, even advised to write the include/require calls without putting
out the parentheses.
if we introduce additional arguments for include/require, the following
code will break:
echo include 'foo.bar', 'baz';
as currently it was interpreted as
echo include('foo.bar'), 'baz';
ofc. we could make that the additional params to include, require would
only used, if the parentheses are uses, but that would make require/include
inconsistent with every other language construct, where the parentheses is
optional.
so we either accept this BC, or not pursue this option, but go with the
new functions/opcodes like include_code/require_code or similar.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

That's sad really, to be honest.
I wonder if people even use this:

echo include 'foo.bar', 'baz';
as currently it was interpreted as
echo include('foo.bar'), 'baz';

I even didn't know it worked that way and if I saw code like this before
today I would consider it an error (I would discover that it actually
works, but I definitively would rewrite that part in two lines as distinct
operators them with ; instead of , between them)

Maybe it's not that big deal and a BC break would not impact things a lot.
What do you think?

13 years ago by Rick WIdmer — view source — reply

unread

That's sad really, to be honest.
I wonder if people even use this:

echo include 'foo.bar', 'baz';

Probably not, Try it! you get:

1baz

It actually works more like

echo (include "foo.bar"), 'baz';

than

echo include( "foo.bar"), 'baz';

More important include doesn't currently allow multiple parms:

include "foo.bar", 'baz';

Parse error: syntax error, unexpected ',' in bla.php on line xx

Rick

13 years ago by Kris Craig — view source — reply

unread

On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmer vchkpw@developersdesk.comwrote:

That's sad really, to be honest.
I wonder if people even use this:

echo include 'foo.bar', 'baz';

Probably not, Try it! you get:

1baz

It actually works more like

echo (include "foo.bar"), 'baz';

than

echo include( "foo.bar"), 'baz';

More important include doesn't currently allow multiple parms:

include "foo.bar", 'baz';

Parse error: syntax error, unexpected ',' in bla.php on line xx

Rick

--

I'll reiterate my position that I'm not ready to bring my RFC to a vote;
and even if I was, the rules wouldn't allow it. In fact, unless I'm
mistaken, none of the RFCs have met the 2-week minimum requirement yet, so
no vote can take place at this time. But I do think we're making progress,
so I would ask for a little extra patience from the peanut gallery for
now. =)

To Arvids' point, I'm definitely leaning in that direction, but I'd like to
hear a little bit more from anyone who believes a different approach would
be better. If nobody speaks-up, I'll just assume that we have consensus on
that point and add it to the RFC.

Regarding include/require, I agree that any BC break would be extremely
minimal. In the 10+ years I've been developing PHP, I don't think I've
ever once seen somebody include multiple scripts on a single line (I wasn't
even aware that such a thing was allowed). So if it does pose a change,
I'd be surprised if any existing scripts would be affected. And since this
is a major version increment we're talking about here, I think a small
amount of allowance can be made for low-impact BC breakage IMHO.

How about we just keep the parentheses optional and comma-seperate the
arguments? For example, the require syntax could look like this:

require[(] $script_filename, $script_type = PHP_SCRIPT_TYPE_NORMAL [)];

Possible values for $script_type:

PHP_SCRIPT_TYPE_NORMAL (0x01)

If the included file contains PHP code, parse it.

PHP_SCRIPT_TYPE_TAGLESS (0x02)

Code is assumed to be PHP throughout the script. The <?php tag throws
E_NOTICE and the ?> tag throws E_RECOVERABLE_ERROR.

PHP_SCRIPT_TYPE_STACK (0x04)

The $script_type is applied to all child scripts of the one being
included.
Question : Would anyone see value in adding an override constant that,
while not recommended, allows the developer to apply a different
$script_type somewhere deeper in the stack? Personally this doesn't sound
useful to me, but I'd be willing to put it in if enough of you wanted it.

PHP_SCRIPT_TYPE_CODE_FILE (PHP_SCRIPT_TYPE_NORMAL & PHP_SCRIPT_TYPE_TAGLESS)

The entire script is assumed to be PHP code and is parsed accordingly.

PHP_SCRIPT_TYPE_CODE_STACK (PHP_SCRIPT_TYPE_NORMAL &
PHP_SCRIPT_TYPE_TAGLESS & PHP_SCRIPT_TYPE_STACK)

The entire script and all its child scripts (i.e. its "stack") are
assumed to be PHP code and parsed accordingly.

What do you think?

--Kris

13 years ago by Rick WIdmer — view source — reply

unread

On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmervchkpw@developersdesk.comwrote:

More important include doesn't currently allow multiple parms:

include "foo.bar", 'baz';

Parse error: syntax error, unexpected ',' in bla.php on line xx

Regarding include/require, I agree that any BC break would be extremely
minimal. In the 10+ years I've been developing PHP, I don't think I've
ever once seen somebody include multiple scripts on a single line (I wasn't
even aware that such a thing was allowed).

See above. It is not allowed now.

How about we just keep the parentheses optional and comma-seperate the
arguments? For example, the require syntax could look like this:

require[(] $script_filename, $script_type = PHP_SCRIPT_TYPE_NORMAL [)];

include/require are language constructs. They do not require () around
the parms, and making it optional probably isn't reasonable. OTOH,
since it currently only allows one parm, adding a second, optional parm
should be no problem.

13 years ago by Nikita Popov — view source — reply

unread

On Mon, Apr 16, 2012 at 10:31 AM, Rick
WIdmervchkpw@developersdesk.comwrote:

More important include doesn't currently allow multiple parms:

include "foo.bar", 'baz';

Parse error: syntax error, unexpected ',' in bla.php on line xx
Regarding include/require, I agree that any BC break would be extremely
minimal. In the 10+ years I've been developing PHP, I don't think I've
ever once seen somebody include multiple scripts on a single line (I
wasn't even aware that such a thing was allowed).
See above. It is not allowed now.

I think there is a misunderstanding here. Inclusions with two
arguments are currently not allowed, yes. The point is that adding
such a second argument would make the grammar ambiguous.

E.g, consider this:

func(include 'foo', $someThing);

Currently this is interpreted as the return value of 'foo' and the
variable $someThing being passed to func.

If you add a second argument it's unclear what this does. Is this a
two-argument include? I.e. should it be interpreted as

func((include 'foo', $someThing));

Or is this a one-argument include and should be interpreted as

func((include 'foo'), $someThing);

In my eyes such an ambiguity renders any proposal to add another
argument to include completely unacceptable.

The only option is to add a dedicated syntax for it like

include 'foo' as $flags;

Nikita

13 years ago by Kris Craig — view source — reply

unread

On Mon, Apr 16, 2012 at 12:51 PM, Nikita Popov nikita.ppv@googlemail.comwrote:

On Mon, Apr 16, 2012 at 9:39 PM, Rick WIdmer vchkpw@developersdesk.com
wrote:

On Mon, Apr 16, 2012 at 10:31 AM, Rick
WIdmervchkpw@developersdesk.comwrote:

More important include doesn't currently allow multiple parms:

include "foo.bar", 'baz';

Parse error: syntax error, unexpected ',' in bla.php on line xx
Regarding include/require, I agree that any BC break would be extremely
minimal. In the 10+ years I've been developing PHP, I don't think I've
ever once seen somebody include multiple scripts on a single line (I
wasn't even aware that such a thing was allowed).
See above. It is not allowed now.

I think there is a misunderstanding here. Inclusions with two
arguments are currently not allowed, yes. The point is that adding
such a second argument would make the grammar ambiguous.

E.g, consider this:

func(include 'foo', $someThing);

Currently this is interpreted as the return value of 'foo' and the
variable $someThing being passed to func.

If you add a second argument it's unclear what this does. Is this a
two-argument include? I.e. should it be interpreted as

func((include 'foo', $someThing));

Or is this a one-argument include and should be interpreted as

func((include 'foo'), $someThing);

In my eyes such an ambiguity renders any proposal to add another
argument to include completely unacceptable.

The only option is to add a dedicated syntax for it like

include 'foo' as $flags;

Nikita

--

Hmm I like that idea. Anyone see any downsides to using "as" instead of
comma delination?

--Kris

13 years ago by Tom Boutell — view source — reply

unread

I think the 'as' solution is smart.

On Mon, Apr 16, 2012 at 12:51 PM, Nikita Popov nikita.ppv@googlemail.comwrote:

On Mon, Apr 16, 2012 at 9:39 PM, Rick WIdmer vchkpw@developersdesk.com
wrote:

On Mon, Apr 16, 2012 at 10:31 AM, Rick
WIdmervchkpw@developersdesk.comwrote:

More important include doesn't currently allow multiple parms:

include "foo.bar", 'baz';

Parse error: syntax error, unexpected ',' in bla.php on line xx
Regarding include/require, I agree that any BC break would be extremely
minimal. In the 10+ years I've been developing PHP, I don't think I've
ever once seen somebody include multiple scripts on a single line (I
wasn't even aware that such a thing was allowed).
See above. It is not allowed now.

I think there is a misunderstanding here. Inclusions with two
arguments are currently not allowed, yes. The point is that adding
such a second argument would make the grammar ambiguous.

E.g, consider this:

func(include 'foo', $someThing);

Currently this is interpreted as the return value of 'foo' and the
variable $someThing being passed to func.

If you add a second argument it's unclear what this does. Is this a
two-argument include? I.e. should it be interpreted as

func((include 'foo', $someThing));

Or is this a one-argument include and should be interpreted as

func((include 'foo'), $someThing);

In my eyes such an ambiguity renders any proposal to add another
argument to include completely unacceptable.

The only option is to add a dedicated syntax for it like

include 'foo' as $flags;

Nikita

--

Hmm I like that idea. Anyone see any downsides to using "as" instead of
comma delination?

--Kris

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

13 years ago by Tom Boutell — view source — reply

unread

This has been added in version 1.1.1 of the
source_files_without_opening_tag RFC:

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

I think the 'as' solution is smart.

On Mon, Apr 16, 2012 at 12:51 PM, Nikita Popov nikita.ppv@googlemail.comwrote:

On Mon, Apr 16, 2012 at 9:39 PM, Rick WIdmer vchkpw@developersdesk.com
wrote:

On Mon, Apr 16, 2012 at 10:31 AM, Rick
WIdmervchkpw@developersdesk.comwrote:

More important include doesn't currently allow multiple parms:

include "foo.bar", 'baz';

Parse error: syntax error, unexpected ',' in bla.php on line xx
Regarding include/require, I agree that any BC break would be extremely
minimal. In the 10+ years I've been developing PHP, I don't think I've
ever once seen somebody include multiple scripts on a single line (I
wasn't even aware that such a thing was allowed).
See above. It is not allowed now.

I think there is a misunderstanding here. Inclusions with two
arguments are currently not allowed, yes. The point is that adding
such a second argument would make the grammar ambiguous.

E.g, consider this:

func(include 'foo', $someThing);

Currently this is interpreted as the return value of 'foo' and the
variable $someThing being passed to func.

If you add a second argument it's unclear what this does. Is this a
two-argument include? I.e. should it be interpreted as

func((include 'foo', $someThing));

Or is this a one-argument include and should be interpreted as

func((include 'foo'), $someThing);

In my eyes such an ambiguity renders any proposal to add another
argument to include completely unacceptable.

The only option is to add a dedicated syntax for it like

include 'foo' as $flags;

Nikita

--

Hmm I like that idea. Anyone see any downsides to using "as" instead of
comma delination?

--Kris

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

13 years ago by Kris Craig — view source — reply

unread

Hey guys, can we move the RFC updates back to the threads for each RFC?
Subsequent discussion should go there as well.

--Kris

This has been added in version 1.1.1 of the
source_files_without_opening_tag RFC:

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

I think the 'as' solution is smart.

On Mon, Apr 16, 2012 at 3:54 PM, Kris Craig kris.craig@gmail.com
wrote:

On Mon, Apr 16, 2012 at 12:51 PM, Nikita Popov <
nikita.ppv@googlemail.com>wrote:

On Mon, Apr 16, 2012 at 9:39 PM, Rick WIdmer <
vchkpw@developersdesk.com>
wrote:

On Mon, Apr 16, 2012 at 10:31 AM, Rick
WIdmervchkpw@developersdesk.comwrote:

More important include doesn't currently allow multiple parms:

include "foo.bar", 'baz';

Parse error: syntax error, unexpected ',' in bla.php on line xx
Regarding include/require, I agree that any BC break would be
extremely
minimal. In the 10+ years I've been developing PHP, I don't think
I've
ever once seen somebody include multiple scripts on a single line (I
wasn't even aware that such a thing was allowed).
See above. It is not allowed now.

I think there is a misunderstanding here. Inclusions with two
arguments are currently not allowed, yes. The point is that adding
such a second argument would make the grammar ambiguous.

E.g, consider this:

func(include 'foo', $someThing);

Currently this is interpreted as the return value of 'foo' and the
variable $someThing being passed to func.

If you add a second argument it's unclear what this does. Is this a
two-argument include? I.e. should it be interpreted as

func((include 'foo', $someThing));

Or is this a one-argument include and should be interpreted as

func((include 'foo'), $someThing);

In my eyes such an ambiguity renders any proposal to add another
argument to include completely unacceptable.

The only option is to add a dedicated syntax for it like

include 'foo' as $flags;

Nikita

--

Hmm I like that idea. Anyone see any downsides to using "as" instead of
comma delination?

--Kris

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

13 years ago by Arpad Ray — view source — reply

unread

Please excuse me for butting in without immediate context. I'd just like to
support the idea of a vote on this concept without getting into specifics.

If the vote is positive then we can argue the various merits of the
competing RFCs knowing that we at least agree in general. On the other hand
if the vote is negative, we can save a significant amount of time and
effort, and can concentrate on more plausible subjects.

Cheers,

Arpad

13 years ago by Tom Boutell — view source — reply

unread

Such a vote would make sense if it were clearly expressed that the
final RFC would also be subject to a binding vote, so there is no risk
of being forced to accept an implementation whose particular details
are unacceptable to you.

Please excuse me for butting in without immediate context. I'd just like to
support the idea of a vote on this concept without getting into specifics.

If the vote is positive then we can argue the various merits of the
competing RFCs knowing that we at least agree in general. On the other hand
if the vote is negative, we can save a significant amount of time and
effort, and can concentrate on more plausible subjects.

Cheers,

Arpad

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

13 years ago by Kris Craig — view source — reply

unread

Such a vote would make sense if it were clearly expressed that the
final RFC would also be subject to a binding vote, so there is no risk
of being forced to accept an implementation whose particular details
are unacceptable to you.

Please excuse me for butting in without immediate context. I'd just like
to
support the idea of a vote on this concept without getting into
specifics.

If the vote is positive then we can argue the various merits of the
competing RFCs knowing that we at least agree in general. On the other
hand
if the vote is negative, we can save a significant amount of time and
effort, and can concentrate on more plausible subjects.

Cheers,

Arpad

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

--

Problem is, the RFC voting process currently does not allow for this. You
could take an informal vote, but I honestly don't see much value in that
given that we've already invested ourselves in this.

Any opinions on my idea of creating an RFC to expand the voting
procedures? I'd be more than happy to draft one, but only if it's
something people would actually be interested in. So far, the lack of
response suggests to me that there is no interest in that, in which case we
should accept the voting process as-is and vote on each RFC as a whole
after the prescribed 2-week minimum discussion period.

--Kris

13 years ago by Arvids Godjuks — view source — reply

unread

16 апреля 2012 г. 22:02 пользователь Kris Craig kris.craig@gmail.comнаписал:

On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmer <vchkpw@developersdesk.com

wrote:

That's sad really, to be honest.
I wonder if people even use this:

echo include 'foo.bar', 'baz';

Probably not, Try it! you get:

1baz

It actually works more like

echo (include "foo.bar"), 'baz';

than

echo include( "foo.bar"), 'baz';

More important include doesn't currently allow multiple parms:

include "foo.bar", 'baz';

Parse error: syntax error, unexpected ',' in bla.php on line xx

Rick

--

I'll reiterate my position that I'm not ready to bring my RFC to a vote;
and even if I was, the rules wouldn't allow it. In fact, unless I'm
mistaken, none of the RFCs have met the 2-week minimum requirement yet, so
no vote can take place at this time. But I do think we're making progress,
so I would ask for a little extra patience from the peanut gallery for
now. =)

To Arvids' point, I'm definitely leaning in that direction, but I'd like to
hear a little bit more from anyone who believes a different approach would
be better. If nobody speaks-up, I'll just assume that we have consensus on
that point and add it to the RFC.

Regarding include/require, I agree that any BC break would be extremely
minimal. In the 10+ years I've been developing PHP, I don't think I've
ever once seen somebody include multiple scripts on a single line (I wasn't
even aware that such a thing was allowed). So if it does pose a change,
I'd be surprised if any existing scripts would be affected. And since this
is a major version increment we're talking about here, I think a small
amount of allowance can be made for low-impact BC breakage IMHO.

How about we just keep the parentheses optional and comma-seperate the
arguments? For example, the require syntax could look like this:

require[(] $script_filename, $script_type = PHP_SCRIPT_TYPE_NORMAL [)];

Possible values for $script_type:

PHP_SCRIPT_TYPE_NORMAL (0x01)

If the included file contains PHP code, parse it.

PHP_SCRIPT_TYPE_TAGLESS (0x02)

Code is assumed to be PHP throughout the script. The <?php tag throws
E_NOTICE and the ?> tag throws E_RECOVERABLE_ERROR.

PHP_SCRIPT_TYPE_STACK (0x04)

The $script_type is applied to all child scripts of the one being
included.

Question : Would anyone see value in adding an override constant that,
while not recommended, allows the developer to apply a different
$script_type somewhere deeper in the stack? Personally this doesn't
sound
useful to me, but I'd be willing to put it in if enough of you wanted it.

PHP_SCRIPT_TYPE_CODE_FILE (PHP_SCRIPT_TYPE_NORMAL &
PHP_SCRIPT_TYPE_TAGLESS)

The entire script is assumed to be PHP code and is parsed accordingly.

PHP_SCRIPT_TYPE_CODE_STACK (PHP_SCRIPT_TYPE_NORMAL &
PHP_SCRIPT_TYPE_TAGLESS & PHP_SCRIPT_TYPE_STACK)

The entire script and all its child scripts (i.e. its "stack") are
assumed to be PHP code and parsed accordingly.

What do you think?

--Kris

I think there is no need for that many constants and types of inclusion.
Just a PHP_SCRIPT_TYPE_NORMAL and PHP_SCRIPT_TYPE_CODE will suffice (the
later just expects the <?php at the very beginning of the file, like a
header, and no other ?> or <?= or <?php through the file). The KISS
principle still applies, and it should be kept that way. Too many options
and you end up with people abusing that on purpose with reasoning "Because
I can, f**k everybody else!" (it's a "pleasure" to work with such people).
I don't like the idea of removing the <?php tag at all, because it will
mess up the syntax highlighting everywhere and annoy people that copy the
plain code without the <?php and get it not recognized as a valid source
code.

13 years ago by Kris Craig — view source — reply

unread

On Mon, Apr 16, 2012 at 3:55 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

16 апреля 2012 г. 22:02 пользователь Kris Craig kris.craig@gmail.comнаписал:

On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmer <vchkpw@developersdesk.com

wrote:

That's sad really, to be honest.
I wonder if people even use this:

echo include 'foo.bar', 'baz';

Probably not, Try it! you get:

1baz

It actually works more like

echo (include "foo.bar"), 'baz';

than

echo include( "foo.bar"), 'baz';

More important include doesn't currently allow multiple parms:

include "foo.bar", 'baz';

Parse error: syntax error, unexpected ',' in bla.php on line xx

Rick

--

I'll reiterate my position that I'm not ready to bring my RFC to a vote;
and even if I was, the rules wouldn't allow it. In fact, unless I'm
mistaken, none of the RFCs have met the 2-week minimum requirement yet, so
no vote can take place at this time. But I do think we're making
progress,
so I would ask for a little extra patience from the peanut gallery for
now. =)

To Arvids' point, I'm definitely leaning in that direction, but I'd like
to
hear a little bit more from anyone who believes a different approach would
be better. If nobody speaks-up, I'll just assume that we have consensus
on
that point and add it to the RFC.

Regarding include/require, I agree that any BC break would be extremely
minimal. In the 10+ years I've been developing PHP, I don't think I've
ever once seen somebody include multiple scripts on a single line (I
wasn't
even aware that such a thing was allowed). So if it does pose a change,
I'd be surprised if any existing scripts would be affected. And since
this
is a major version increment we're talking about here, I think a small
amount of allowance can be made for low-impact BC breakage IMHO.

How about we just keep the parentheses optional and comma-seperate the
arguments? For example, the require syntax could look like this:

require[(] $script_filename, $script_type = PHP_SCRIPT_TYPE_NORMAL [)];

Possible values for $script_type:

PHP_SCRIPT_TYPE_NORMAL (0x01)

If the included file contains PHP code, parse it.

PHP_SCRIPT_TYPE_TAGLESS (0x02)

Code is assumed to be PHP throughout the script. The <?php tag throws

E_NOTICE and the ?> tag throws E_RECOVERABLE_ERROR.

PHP_SCRIPT_TYPE_STACK (0x04)

The $script_type is applied to all child scripts of the one being
included.

Question : Would anyone see value in adding an override constant that,

while not recommended, allows the developer to apply a different
$script_type somewhere deeper in the stack? Personally this doesn't
sound
useful to me, but I'd be willing to put it in if enough of you wanted
it.

PHP_SCRIPT_TYPE_CODE_FILE (PHP_SCRIPT_TYPE_NORMAL &
PHP_SCRIPT_TYPE_TAGLESS)

The entire script is assumed to be PHP code and is parsed accordingly.

PHP_SCRIPT_TYPE_CODE_STACK (PHP_SCRIPT_TYPE_NORMAL &
PHP_SCRIPT_TYPE_TAGLESS & PHP_SCRIPT_TYPE_STACK)

The entire script and all its child scripts (i.e. its "stack") are

assumed to be PHP code and parsed accordingly.

What do you think?

--Kris

I think there is no need for that many constants and types of inclusion.
Just a PHP_SCRIPT_TYPE_NORMAL and PHP_SCRIPT_TYPE_CODE will suffice (the
later just expects the <?php at the very beginning of the file, like a
header, and no other ?> or <?= or <?php through the file). The KISS
principle still applies, and it should be kept that way. Too many options
and you end up with people abusing that on purpose with reasoning "Because
I can, f**k everybody else!" (it's a "pleasure" to work with such people).
I don't like the idea of removing the <?php tag at all, because it will
mess up the syntax highlighting everywhere and annoy people that copy the
plain code without the <?php and get it not recognized as a valid source
code.

Restricting it to just those two is a non-starter, period. It would
unravel the compromise solution that has been worked out where three types
exist. And I think a bitwise constant is the most logical approach. Keep
in mind that scalability is a potential factor as well. It's possible
that, at some point in the future, new ideas may emerge that add even more
options to script inclusion, in which case having a flexible bit constant
would allow this to scale without having to add additional arguments or
other needless complexities. In this case, more constants means more
flexibility for the developer IMHO.

--Kris

13 years ago by Tom Boutell — view source — reply

unread

What happens if two of them pass?

On Mon, Apr 16, 2012 at 6:55 PM, Arvids Godjuks
arvids.godjuks@gmail.com wrote:

16 апреля 2012 г. 22:02 пользователь Kris Craig kris.craig@gmail.comнаписал:

On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmer <vchkpw@developersdesk.com

wrote:

That's sad really, to be honest.
I wonder if people even use this:

echo include 'foo.bar', 'baz';

Probably not, Try it! you get:

1baz

It actually works more like

echo (include "foo.bar"), 'baz';

than

echo include( "foo.bar"), 'baz';

More important include doesn't currently allow multiple parms:

include "foo.bar", 'baz';

Parse error: syntax error, unexpected ',' in bla.php on line xx

Rick

--

I'll reiterate my position that I'm not ready to bring my RFC to a vote;
and even if I was, the rules wouldn't allow it. In fact, unless I'm
mistaken, none of the RFCs have met the 2-week minimum requirement yet, so
no vote can take place at this time. But I do think we're making progress,
so I would ask for a little extra patience from the peanut gallery for
now. =)

To Arvids' point, I'm definitely leaning in that direction, but I'd like to
hear a little bit more from anyone who believes a different approach would
be better. If nobody speaks-up, I'll just assume that we have consensus on
that point and add it to the RFC.

Regarding include/require, I agree that any BC break would be extremely
minimal. In the 10+ years I've been developing PHP, I don't think I've
ever once seen somebody include multiple scripts on a single line (I wasn't
even aware that such a thing was allowed). So if it does pose a change,
I'd be surprised if any existing scripts would be affected. And since this
is a major version increment we're talking about here, I think a small
amount of allowance can be made for low-impact BC breakage IMHO.

How about we just keep the parentheses optional and comma-seperate the
arguments? For example, the require syntax could look like this:

require[(] $script_filename, $script_type = PHP_SCRIPT_TYPE_NORMAL [)];

Possible values for $script_type:

PHP_SCRIPT_TYPE_NORMAL (0x01)

- If the included file contains PHP code, parse it.

PHP_SCRIPT_TYPE_TAGLESS (0x02)

- Code is assumed to be PHP throughout the script. The <?php tag throws
E_NOTICE and the ?> tag throws E_RECOVERABLE_ERROR.

PHP_SCRIPT_TYPE_STACK (0x04)

- The $script_type is applied to all child scripts of the one being
included.
- Question : Would anyone see value in adding an override constant that,
while not recommended, allows the developer to apply a different
$script_type somewhere deeper in the stack? Personally this doesn't
sound
useful to me, but I'd be willing to put it in if enough of you wanted it.

PHP_SCRIPT_TYPE_CODE_FILE (PHP_SCRIPT_TYPE_NORMAL &
PHP_SCRIPT_TYPE_TAGLESS)

- The entire script is assumed to be PHP code and is parsed accordingly.

PHP_SCRIPT_TYPE_CODE_STACK (PHP_SCRIPT_TYPE_NORMAL &
PHP_SCRIPT_TYPE_TAGLESS & PHP_SCRIPT_TYPE_STACK)

- The entire script and all its child scripts (i.e. its "stack") are
assumed to be PHP code and parsed accordingly.

What do you think?

--Kris

I think there is no need for that many constants and types of inclusion.
Just a PHP_SCRIPT_TYPE_NORMAL and PHP_SCRIPT_TYPE_CODE will suffice (the
later just expects the <?php at the very beginning of the file, like a
header, and no other ?> or <?= or <?php through the file). The KISS
principle still applies, and it should be kept that way. Too many options
and you end up with people abusing that on purpose with reasoning "Because
I can, f**k everybody else!" (it's a "pleasure" to work with such people).
I don't like the idea of removing the <?php tag at all, because it will
mess up the syntax highlighting everywhere and annoy people that copy the
plain code without the <?php and get it not recognized as a valid source
code.

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

13 years ago by Kris Craig — view source — reply

unread

2012/4/16 Tom Boutell tom@punkave.com

What happens if two of them pass?

Come again?

--Kris

13 years ago by Ferenc Kovacs — view source — reply

unread

Hi,

It would be better to vote

PHP will have script only (tag less) code or not

then

How it will be implemented

Regards,

That idea was raised a few times in the past, but Stas and others
expressed, they (and maybe most people) can only vote for something, if the
implementation details are tailored out (a patch is nice to have, but
not necessary), otherwise you can't measure whether that change is feasible
at all.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

13 years ago by Tom Boutell — view source — reply

unread

We could vote on whether we like the idea in principle, with the condition that the final proposal pass separately as a fully detailed rfc. That way you are telling the authors of these rfcs whether to keep trying and in what direction, but you are not forced to accept the end product. I would welcome such a vote just to end fruitless debate on the three points I mentioned.

Sent from my iPhone

Hi,

It would be better to vote

PHP will have script only (tag less) code or not

then

How it will be implemented

Regards,

That idea was raised a few times in the past, but Stas and others
expressed, they (and maybe most people) can only vote for something, if the
implementation details are tailored out (a patch is nice to have, but
not necessary), otherwise you can't measure whether that change is feasible
at all.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu