Go for votes for the open tag-less PHP files View as Markdown

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

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

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