[RFC] New .phpp File Type for Pure-Code PHP Scripts

13 years ago by Kris Craig — view source

unread

Per recent discussions, I have drafted an RFC for this. This proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less PHP
scripts.

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

--Kris

13 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less PHP
scripts.

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

This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to locate
under docroot?
It relates previous question. How about bootstrap script for frameworks?

A regular .php script cannot be included from a .phpp script. An E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be thrown for require; in both instances, the included file will be ignored.

Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

13 years ago by Arvids Godjuks — view source

unread

So ok, i write my code in files without extension, what happens?

As it was said before, interpreter will not distinguish by the file
extension, ever. It is os dependant and so on.

Why are you poluting the mailing list with things that are clearly said
will never happen?

13 years ago by Kris Craig — view source

unread

On Thu, Apr 12, 2012 at 4:44 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

So ok, i write my code in files without extension, what happens?

As it was said before, interpreter will not distinguish by the file
extension, ever. It is os dependant and so on.

Why are you poluting the mailing list with things that are clearly said
will never happen?

You might want to consider using less inflammatory, disrespectful language
if you want people to respond favorably to your questions. I.e. accusing
someone of "poluting [sic] the mailing list" because they posted an idea
you don't like is neither constructive nor necessary.

That being said, the .php file extension is not, as far as I know,
determined by the operating system. It's determined by the webserver
configuration. So if you have two different extensions, each with a
separate SAPI handler to differentiate between them, there's no reason why
this wouldn't work just fine. After all, the internet didn't explode when
we dropped the .php3 extension. ;P

13 years ago by Arvids Godjuks — view source

unread

Well, I just don't know how i can appeal to common sence to some people on
the list anymore. First the type hinting threads, now this.

The world does not work only on one web server and there are different type
ls of them out there. I for once use nginx and i configure how to run
scripts by locations, not by file types. I just pass the params to fastcgi
server thet runs a php binary. And it does not.care about the extension. I
can use any extension.l for my code. Yes, i use .php, others use. phtml or
other variants. Extensions are just a convension, nothing more. You can
give a file any or none extension at all and it will not change a thing.Ok,
in windows you will not be able to open the file in a program by double
click, but through the open dialog in the app - be my guest. To PHP,
fastcgi and the web server it does not matter. It just matters to people so
they can distingush between a php file, js file and a css file.
13.04.2012 2:01 пользователь "Kris Craig" kris.craig@gmail.com написал:

On Thu, Apr 12, 2012 at 4:44 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

So ok, i write my code in files without extension, what happens?

As it was said before, interpreter will not distinguish by the file
extension, ever. It is os dependant and so on.

Why are you poluting the mailing list with things that are clearly said
will never happen?

You might want to consider using less inflammatory, disrespectful language
if you want people to respond favorably to your questions. I.e. accusing
someone of "poluting [sic] the mailing list" because they posted an idea
you don't like is neither constructive nor necessary.

That being said, the .php file extension is not, as far as I know,
determined by the operating system. It's determined by the webserver
configuration. So if you have two different extensions, each with a
separate SAPI handler to differentiate between them, there's no reason why
this wouldn't work just fine. After all, the internet didn't explode when
we dropped the .php3 extension. ;P

13 years ago by Kris Craig — view source

unread

On Thu, Apr 12, 2012 at 5:26 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

Well, I just don't know how i can appeal to common sence to some people on
the list anymore. First the type hinting threads, now this.

With all due respect, Arvids, get over it. People are going to propose
ideas you don't like. I'm going to propose ideas you don't like. You can
either handle it like a mature adult or you can alienate the very people
you're trying to persuade. I've seen a disturbing pattern of hostile
behavior bordering on abusiveness from you on a number of threads and I
would ask you to take a deep breath and tone it down. If you don't think
you can post a response without engaging in personal attacks and hyperbole,
walk away and come back to it later when you've had a chance to get the
initial emotion out of your system. Spraying the list with insults
whenever someone disagrees with you is not an acceptable way of working
with others IMHO. So please try to work on that.

The world does not work only on one web server and there are different
type ls of them out there. I for once use nginx and i configure how to run
scripts by locations, not by file types. I just pass the params to fastcgi
server thet runs a php binary. And it does not.care about the extension. I
can use any extension.l for my code. Yes, i use .php, others use. phtml or
other variants. Extensions are just a convension, nothing more. You can
give a file any or none extension at all and it will not change a thing.Ok,
in windows you will not be able to open the file in a program by double
click, but through the open dialog in the app - be my guest. To PHP,
fastcgi and the web server it does not matter. It just matters to people so
they can distingush between a php file, js file and a css file.

I'd prefer to avoid getting into a heated argument over something that
amounts to little more than semantics. Yes, file extensions are a
convention by their very nature. And yes, there would need to be some
changes in order to add support for a second parsing type. But you'll
notice that's why I listed the target PHP version as 6.0. A major release
such as that is where one would expect these sorts of fundamental
improvements to be made, plus it gives us a long time to sort out the
technical details since 6.0 won't be coming for at least another few years.

--Kris

13.04.2012 2:01 пользователь "Kris Craig" kris.craig@gmail.com написал:

On Thu, Apr 12, 2012 at 4:44 PM, Arvids Godjuks <arvids.godjuks@gmail.com

wrote:

So ok, i write my code in files without extension, what happens?

As it was said before, interpreter will not distinguish by the file
extension, ever. It is os dependant and so on.

Why are you poluting the mailing list with things that are clearly said
will never happen?

You might want to consider using less inflammatory, disrespectful
language if you want people to respond favorably to your questions. I.e.
accusing someone of "poluting [sic] the mailing list" because they posted
an idea you don't like is neither constructive nor necessary.

That being said, the .php file extension is not, as far as I know,
determined by the operating system. It's determined by the webserver
configuration. So if you have two different extensions, each with a
separate SAPI handler to differentiate between them, there's no reason why
this wouldn't work just fine. After all, the internet didn't explode when
we dropped the .php3 extension. ;P

13 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/13 Arvids Godjuks arvids.godjuks@gmail.com:

So ok, i write my code in files without extension, what happens?

As it was said before, interpreter will not distinguish by the file
extension, ever. It is os dependant and so on.

Why are you poluting the mailing list with things that are clearly said will
never happen?

There aren't any clean solution for script only PHP (yet)

There are 3 methods proposed so far.

php.ini setting that controls embedded-mode
https://wiki.php.net/rfc/nophptags
include/require that loads non-embedded mode
https://wiki.php.net/rfc/source_files_without_opening_tag
file extension that switch to non-embedded mode
https://wiki.php.net/rfc/phpp

All of these have pros and cons.
I prefer mine, but I'll vote +1 for any if one of these
will be accepted.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

13 years ago by David Muir — view source

unread

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less PHP
scripts.

https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to locate
under docroot?
It relates previous question. How about bootstrap script for frameworks?

A regular .php script cannot be included from a .phpp script. An E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be thrown for require; in both instances, the included file will be ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

That's a huge WTF that a templating library can't be written as .phpp,
because it then won't be able to load a template.

David

13 years ago by Kris Craig — view source

unread

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less PHP
scripts.

https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to locate
under docroot?
It relates previous question. How about bootstrap script for frameworks?

A regular .php script cannot be included from a .phpp script. An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
thrown for require; in both instances, the included file will be ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

That's a huge WTF that a templating library can't be written as .phpp,
because it then won't be able to load a template.

That's actually not true. Please refer to the diagram embedded in the RFC.

Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway. The
.phpp file is, at least for the most part, intended to be included from a
regular .php file, which also would include whatever you're using for your
templates. In other words, they can interact just fine; you just can't put
the template upstream from a .phpp file in the include stack-- which,
again, you really shouldn't be doing, anyway, as it's just bad architecture.

David

13 years ago by Arvids Godjuks — view source

unread

Sorry, but how will i load a template then? I do that in a controller whose
file is.plain php code with no html. Now i'm forced to use some kind of
template engine that does not including a template, but parsing it and
replacing keywords with data? I really do not have to put a sarcastic
phrase here, do i?
13.04.2012 2:05 пользователь "Kris Craig" kris.craig@gmail.com написал:

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less PHP
scripts.

https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or
else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to locate
under docroot?
It relates previous question. How about bootstrap script for
frameworks?

A regular .php script cannot be included from a .phpp script. An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
thrown for require; in both instances, the included file will be ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

That's a huge WTF that a templating library can't be written as .phpp,
because it then won't be able to load a template.

That's actually not true. Please refer to the diagram embedded in the RFC.

Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway. The
.phpp file is, at least for the most part, intended to be included from a
regular .php file, which also would include whatever you're using for your
templates. In other words, they can interact just fine; you just can't put
the template upstream from a .phpp file in the include stack-- which,
again, you really shouldn't be doing, anyway, as it's just bad
architecture.

David

13 years ago by David Muir — view source

unread

On Thu, Apr 12, 2012 at 4:46 PM, David Muir <davidkmuir@gmail.com
mailto:davidkmuir@gmail.com> wrote:
> Hi,
>
> 2012/4/13 Kris Craig <kris.craig@gmail.com
<mailto:kris.craig@gmail.com>>:
>> Per recent discussions, I have drafted an RFC for this.  This
proposal
>> offers what I believe to be a more sane and realistic approach to
>> addressing the question of incorporating a new breed of
tag-less PHP
>> scripts.
>>
>> https://wiki.php.net/rfc/phpp
> This may work for LFI issue for new codes.
> Few questions.
>
> CLI may use .phpp as PHP script always. (i.e. execute w/o &lt;?php
or else)
> It's like DOS, though.
>
> How do you enforce .phpp as script only for Web?
> Is it a rule for configuration? or .phpp just never supposed to
locate
> under docroot?
> It relates previous question. How about bootstrap script for
frameworks?
>
>> A regular .php script cannot be included from a .phpp script.
An `E_WARNING` will be thrown for include and an `E_RECOVERABLE_ERROR` 
will be thrown for require; in both instances, the included file
will be ignored.
> Some people may try to make .phpp handled by web.
> I cannot tell if this setting is going to be popular, but if it
> does, isn't it the end of embedded PHP?
> It might be good if PHP is more tolerant for this usage.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net <mailto:yohgaki@ohgaki.net>
>

That's a huge WTF that a templating library can't be written as .phpp,
because it then won't be able to load a template.
That's actually not true. Please refer to the diagram embedded in the
RFC.

Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway. The
.phpp file is, at least for the most part, intended to be included
from a regular .php file, which also would include whatever you're
using for your templates. In other words, they can interact just
fine; you just can't put the template upstream from a .phpp file in
the include stack-- which, again, you really shouldn't be doing,
anyway, as it's just bad architecture.

How is this bad architecture? Every framework I've seen that has some
kind of templating layer that handles the scope and inclusion of the
template, and it happens further down the chain from the controlling code.

Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
otherwise they wouldn't be able to render the templates.

In the case of Zend Framwork, which I'm most familiar with, the
application, front controller, dispatcher, and action controllers, and
some services would have to remain as .php so that templates could be
executed.

Oh, and the autoloader can't be .phpp either. But then if it's .php,
then the autoloader can't be called from .phpp files to include .php files.

Cheers,
David

13 years ago by Kris Craig — view source

unread

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less PHP
scripts.

https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to locate
under docroot?
It relates previous question. How about bootstrap script for frameworks?

A regular .php script cannot be included from a .phpp script. An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
thrown for require; in both instances, the included file will be ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

That's a huge WTF that a templating library can't be written as .phpp,
because it then won't be able to load a template.

That's actually not true. Please refer to the diagram embedded in the RFC.

Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway. The
.phpp file is, at least for the most part, intended to be included from a
regular .php file, which also would include whatever you're using for your
templates. In other words, they can interact just fine; you just can't put
the template upstream from a .phpp file in the include stack-- which,
again, you really shouldn't be doing, anyway, as it's just bad architecture.

How is this bad architecture? Every framework I've seen that has some kind
of templating layer that handles the scope and inclusion of the template,
and it happens further down the chain from the controlling code.

Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
otherwise they wouldn't be able to render the templates.

In the case of Zend Framwork, which I'm most familiar with, the
application, front controller, dispatcher, and action controllers, and some
services would have to remain as .php so that templates could be executed.

Oh, and the autoloader can't be .phpp either. But then if it's .php, then
the autoloader can't be called from .phpp files to include .php files.

Cheers,
David

It's been awhile since I've used Smarty, but unless my memory is failing
me, I'm pretty sure it's not restricted to being several points removed
upstream as you described. I'm not familiar with Zend_View or Twig so I
can't comment on those.

Thing is, there's no reason why you can't hook any framework into this.
Worst-case scenario, if the library you're hooking into has a rigid
structure, just write a simple controller class layer to operate on top of
it, then use that same controller class to interface with the .phpp stack.
Problem solved. It's really not as complicated or confusing as you're
making it out to be.

--Kris

13 years ago by Arvids Godjuks — view source

unread

Well, i can say that any template engine that is not a pure php extension
does template inclusion via an include of a file with html and embedded php
code. Because to make things fast you have to convert your templates from
tags and pseudo code to that state and cache the result so not to make
parsing on every request.

And right now there is a standard for autoloading the libraries and
frameworks that most big players agreed on, that will make loading of 3rd
party stuff easy. Untill one converts to pphp and other does not.
Autoloadijg will just break because of mixed approaches.

Hm, you wrote that you have configured php only with IIS and Apache (any
*nix expirience?). Try nginx, see for yourself how different it is.
13.04.2012 3:05 пользователь "Kris Craig" kris.craig@gmail.com написал:

On Thu, Apr 12, 2012 at 4:46 PM, David Muir davidkmuir@gmail.com
wrote:

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This
proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less PHP
scripts.

https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or
else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to locate
under docroot?
It relates previous question. How about bootstrap script for
frameworks?

A regular .php script cannot be included from a .phpp script. An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
thrown for require; in both instances, the included file will be
ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

That's a huge WTF that a templating library can't be written as .phpp,
because it then won't be able to load a template.

That's actually not true. Please refer to the diagram embedded in the
RFC.

Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway. The
.phpp file is, at least for the most part, intended to be included from a
regular .php file, which also would include whatever you're using for
your
templates. In other words, they can interact just fine; you just can't
put
the template upstream from a .phpp file in the include stack-- which,
again, you really shouldn't be doing, anyway, as it's just bad
architecture.

How is this bad architecture? Every framework I've seen that has some
kind
of templating layer that handles the scope and inclusion of the template,
and it happens further down the chain from the controlling code.

Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
otherwise they wouldn't be able to render the templates.

In the case of Zend Framwork, which I'm most familiar with, the
application, front controller, dispatcher, and action controllers, and
some
services would have to remain as .php so that templates could be
executed.

Oh, and the autoloader can't be .phpp either. But then if it's .php, then
the autoloader can't be called from .phpp files to include .php files.

Cheers,
David

It's been awhile since I've used Smarty, but unless my memory is failing
me, I'm pretty sure it's not restricted to being several points removed
upstream as you described. I'm not familiar with Zend_View or Twig so I
can't comment on those.

Thing is, there's no reason why you can't hook any framework into this.
Worst-case scenario, if the library you're hooking into has a rigid
structure, just write a simple controller class layer to operate on top of
it, then use that same controller class to interface with the .phpp stack.
Problem solved. It's really not as complicated or confusing as you're
making it out to be.

--Kris

13 years ago by Yasuo Ohgaki — view source

unread

2012/4/13 Arvids Godjuks arvids.godjuks@gmail.com:

Well, i can say that any template engine that is not a pure php extension
does template inclusion via an include of a file with html and embedded php
code. Because to make things fast you have to convert your templates from
tags and pseudo code to that state and cache the result so not to make
parsing on every request.

And right now there is a standard for autoloading the libraries and
frameworks that most big players agreed on, that will make loading of 3rd
party stuff easy. Untill one converts to pphp and other does not.
Autoloadijg will just break because of mixed approaches.

Good point.

Although there may be name conflicts, script/script_once would
be better and has more compatibility. Let just make types of
include decided how it behave.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Hm, you wrote that you have configured php only with IIS and Apache (any
*nix expirience?). Try nginx, see for yourself how different it is.

13.04.2012 3:05 пользователь "Kris Craig" kris.craig@gmail.com написал:

On 13/04/12 10:04, Kris Craig wrote:

On Thu, Apr 12, 2012 at 4:46 PM, David Muir davidkmuir@gmail.com
wrote:

On 13/04/12 09:38, Yasuo Ohgaki wrote:

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This
proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less PHP
scripts.

https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or
else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to
locate
under docroot?
It relates previous question. How about bootstrap script for
frameworks?

A regular .php script cannot be included from a .phpp script. An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
thrown for require; in both instances, the included file will be
ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

That's a huge WTF that a templating library can't be written as .phpp,
because it then won't be able to load a template.

That's actually not true. Please refer to the diagram embedded in the
RFC.

Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway. The
.phpp file is, at least for the most part, intended to be included from
a
regular .php file, which also would include whatever you're using for
your
templates. In other words, they can interact just fine; you just can't
put
the template upstream from a .phpp file in the include stack-- which,
again, you really shouldn't be doing, anyway, as it's just bad
architecture.

How is this bad architecture? Every framework I've seen that has some
kind
of templating layer that handles the scope and inclusion of the
template,
and it happens further down the chain from the controlling code.

Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
otherwise they wouldn't be able to render the templates.

In the case of Zend Framwork, which I'm most familiar with, the
application, front controller, dispatcher, and action controllers, and
some
services would have to remain as .php so that templates could be
executed.

Oh, and the autoloader can't be .phpp either. But then if it's .php,
then
the autoloader can't be called from .phpp files to include .php files.

Cheers,
David

It's been awhile since I've used Smarty, but unless my memory is failing
me, I'm pretty sure it's not restricted to being several points removed
upstream as you described. I'm not familiar with Zend_View or Twig so I
can't comment on those.

Thing is, there's no reason why you can't hook any framework into this.
Worst-case scenario, if the library you're hooking into has a rigid
structure, just write a simple controller class layer to operate on top of
it, then use that same controller class to interface with the .phpp stack.
Problem solved. It's really not as complicated or confusing as you're
making it out to be.

--Kris

13 years ago by Tom Boutell — view source

unread

The meaning is unclear, and it doesn't let you specify error reporting.

Sent from my iPhone

2012/4/13 Arvids Godjuks arvids.godjuks@gmail.com:

Well, i can say that any template engine that is not a pure php extension
does template inclusion via an include of a file with html and embedded php
code. Because to make things fast you have to convert your templates from
tags and pseudo code to that state and cache the result so not to make
parsing on every request.

And right now there is a standard for autoloading the libraries and
frameworks that most big players agreed on, that will make loading of 3rd
party stuff easy. Untill one converts to pphp and other does not.
Autoloadijg will just break because of mixed approaches.

Good point.

Although there may be name conflicts, script/script_once would
be better and has more compatibility. Let just make types of
include decided how it behave.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Hm, you wrote that you have configured php only with IIS and Apache (any
*nix expirience?). Try nginx, see for yourself how different it is.

13.04.2012 3:05 пользователь "Kris Craig" kris.craig@gmail.com написал:

On Thu, Apr 12, 2012 at 4:46 PM, David Muir davidkmuir@gmail.com
wrote:

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This
proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less PHP
scripts.

https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or
else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to
locate
under docroot?
It relates previous question. How about bootstrap script for
frameworks?

A regular .php script cannot be included from a .phpp script. An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
thrown for require; in both instances, the included file will be
ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

That's a huge WTF that a templating library can't be written as .phpp,
because it then won't be able to load a template.

That's actually not true. Please refer to the diagram embedded in the
RFC.

Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway. The
.phpp file is, at least for the most part, intended to be included from
a
regular .php file, which also would include whatever you're using for
your
templates. In other words, they can interact just fine; you just can't
put
the template upstream from a .phpp file in the include stack-- which,
again, you really shouldn't be doing, anyway, as it's just bad
architecture.

How is this bad architecture? Every framework I've seen that has some
kind
of templating layer that handles the scope and inclusion of the
template,
and it happens further down the chain from the controlling code.

Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
otherwise they wouldn't be able to render the templates.

In the case of Zend Framwork, which I'm most familiar with, the
application, front controller, dispatcher, and action controllers, and
some
services would have to remain as .php so that templates could be
executed.

Oh, and the autoloader can't be .phpp either. But then if it's .php,
then
the autoloader can't be called from .phpp files to include .php files.

Cheers,
David

It's been awhile since I've used Smarty, but unless my memory is failing
me, I'm pretty sure it's not restricted to being several points removed
upstream as you described. I'm not familiar with Zend_View or Twig so I
can't comment on those.

Thing is, there's no reason why you can't hook any framework into this.
Worst-case scenario, if the library you're hooking into has a rigid
structure, just write a simple controller class layer to operate on top of
it, then use that same controller class to interface with the .phpp stack.
Problem solved. It's really not as complicated or confusing as you're
making it out to be.

--Kris

13 years ago by Kris Craig — view source

unread

On Thu, Apr 12, 2012 at 6:26 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

Well, i can say that any template engine that is not a pure php extension
does template inclusion via an include of a file with html and embedded php
code. Because to make things fast you have to convert your templates from
tags and pseudo code to that state and cache the result so not to make
parsing on every request.

And right now there is a standard for autoloading the libraries and
frameworks that most big players agreed on, that will make loading of 3rd
party stuff easy. Untill one converts to pphp and other does not.
Autoloadijg will just break because of mixed approaches.

The autoloading standard is still more or less in its infancy IMHO; the MVC
standard, on the other hand, has been around for awhile and is widely
accepted. I haven't done any detailed work with the autoloading standard,
but I'll look into it. I can't imagine though that it would be so
inflexible as to make it completely incompatible with existing MVC
standards. If that was the case, then I can't imagine ever wanting to use
that, anyway.

Hm, you wrote that you have configured php only with IIS and Apache (any
*nix expirience?). Try nginx, see for yourself how different it is.

You are aware that Apache runs on both Windows and Linux, right? It's the
"A" in "LAMP", after all. ;P

13.04.2012 3:05 пользователь "Kris Craig" kris.craig@gmail.com написал:

On Thu, Apr 12, 2012 at 4:46 PM, David Muir davidkmuir@gmail.com
wrote:

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This
proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less PHP
scripts.

https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or
else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to
locate
under docroot?
It relates previous question. How about bootstrap script for
frameworks?

A regular .php script cannot be included from a .phpp script. An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
thrown for require; in both instances, the included file will be
ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

That's a huge WTF that a templating library can't be written as .phpp,
because it then won't be able to load a template.

That's actually not true. Please refer to the diagram embedded in the
RFC.

Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway. The
.phpp file is, at least for the most part, intended to be included from
a
regular .php file, which also would include whatever you're using for
your
templates. In other words, they can interact just fine; you just can't
put
the template upstream from a .phpp file in the include stack-- which,
again, you really shouldn't be doing, anyway, as it's just bad
architecture.

How is this bad architecture? Every framework I've seen that has some
kind
of templating layer that handles the scope and inclusion of the
template,
and it happens further down the chain from the controlling code.

Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
otherwise they wouldn't be able to render the templates.

In the case of Zend Framwork, which I'm most familiar with, the
application, front controller, dispatcher, and action controllers, and
some
services would have to remain as .php so that templates could be
executed.

Oh, and the autoloader can't be .phpp either. But then if it's .php,
then
the autoloader can't be called from .phpp files to include .php files.

Cheers,
David

It's been awhile since I've used Smarty, but unless my memory is failing
me, I'm pretty sure it's not restricted to being several points removed
upstream as you described. I'm not familiar with Zend_View or Twig so I
can't comment on those.

Thing is, there's no reason why you can't hook any framework into this.
Worst-case scenario, if the library you're hooking into has a rigid
structure, just write a simple controller class layer to operate on top of
it, then use that same controller class to interface with the .phpp stack.
Problem solved. It's really not as complicated or confusing as you're
making it out to be.

--Kris

13 years ago by David Muir — view source

unread

>
>
> On Thu, Apr 12, 2012 at 5:46 PM, David Muir > > wrote:
>
>
>>
>>
>> On Thu, Apr 12, 2012 at 4:46 PM, David Muir >> > wrote:
>>
>>
>> > Hi,
>> >
>> > 2012/4/13 Kris Craig >> >:
>> >> Per recent discussions, I have drafted an RFC for this.
>> This proposal
>> >> offers what I believe to be a more sane and realistic
>> approach to
>> >> addressing the question of incorporating a new breed of
>> tag-less PHP
>> >> scripts.
>> >>
>> >> https://wiki.php.net/rfc/phpp
>> > This may work for LFI issue for new codes.
>> > Few questions.
>> >
>> > CLI may use .phpp as PHP script always. (i.e. execute w/o
>> <?php or else)
>> > It's like DOS, though.
>> >
>> > How do you enforce .phpp as script only for Web?
>> > Is it a rule for configuration? or .phpp just never
>> supposed to locate
>> > under docroot?
>> > It relates previous question. How about bootstrap script
>> for frameworks?
>> >
>> >> A regular .php script cannot be included from a .phpp
>> script. An `E_WARNING` will be thrown for include and an
>> `E_RECOVERABLE_ERROR` will be thrown for require; in both
>> instances, the included file will be ignored.
>> > Some people may try to make .phpp handled by web.
>> > I cannot tell if this setting is going to be popular, but if it
>> > does, isn't it the end of embedded PHP?
>> > It might be good if PHP is more tolerant for this usage.
>> >
>> > Regards,
>> >
>> > --
>> > Yasuo Ohgaki
>> > yohgaki@ohgaki.net
>> >
>>
>> That's a huge WTF that a templating library can't be written
>> as .phpp,
>> because it then won't be able to load a template.
>>
>>
>> That's actually not true. Please refer to the diagram embedded
>> in the RFC.
>>
>> Basically, you can load a template just fine-- you just can't do
>> it directly from a .phpp file, which you shouldn't be doing,
>> anyway. The .phpp file is, at least for the most part, intended
>> to be included from a regular .php file, which also would include
>> whatever you're using for your templates. In other words, they
>> can interact just fine; you just can't put the template upstream
>> from a .phpp file in the include stack-- which, again, you really
>> shouldn't be doing, anyway, as it's just bad architecture.
>>
>
> How is this bad architecture? Every framework I've seen that has
> some kind of templating layer that handles the scope and inclusion
> of the template, and it happens further down the chain from the
> controlling code.
>
> Zend_View, Twig or Smarty would have to remain as .php and not
> .phpp, otherwise they wouldn't be able to render the templates.
>
> In the case of Zend Framwork, which I'm most familiar with, the
> application, front controller, dispatcher, and action controllers,
> and some services would have to remain as .php so that templates
> could be executed.
>
> Oh, and the autoloader can't be .phpp either. But then if it's
> .php, then the autoloader can't be called from .phpp files to
> include .php files.
>
> Cheers,
> David
>
>
> It's been awhile since I've used Smarty, but unless my memory is
> failing me, I'm pretty sure it's not restricted to being several
> points removed upstream as you described. I'm not familiar with
> Zend_View or Twig so I can't comment on those.
>
> Thing is, there's no reason why you can't hook any framework into
> this. Worst-case scenario, if the library you're hooking into has a
> rigid structure, just write a simple controller class layer to operate
> on top of it, then use that same controller class to interface with
> the .phpp stack. Problem solved. It's really not as complicated or
> confusing as you're making it out to be.
>
> --Kris
>

Both Smarty and Twig compile your template files down to php templates.
Zend_View, Aura.View, and Symfony's php view include php files directly
without a compilation phase.

I don't get how I would write a "simple controller class layer to
operate on top of it".

Does the inclusion limitation apply to just the script in question, or
the entire call stack?

A simplified example:
index.php -> FrontController.phpp -> Controller.phpp -> View.phpp ->
can't include template.phtml

index.php -> FrontController.phpp -> Controller.phpp -> View.php -> can
include template.phtml ?
But I can't do require_once('View.php') in the controller.

If there's an autoloader involved, it would have to be set up in
index.php, and would also have to be .php so that it can include both
file types.

index.php -> FrontController.phpp -> Controller.phpp -> Autoloader.php
-> can include View.php ?

But will that work since there are .phpp files above it in the call stack?

Cheers,
David

13 years ago by Kris Craig — view source

unread

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less PHP
scripts.

https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or
else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to locate
under docroot?
It relates previous question. How about bootstrap script for
frameworks?

A regular .php script cannot be included from a .phpp script. An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
thrown for require; in both instances, the included file will be ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

That's a huge WTF that a templating library can't be written as .phpp,
because it then won't be able to load a template.

That's actually not true. Please refer to the diagram embedded in the
RFC.

Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway. The
.phpp file is, at least for the most part, intended to be included from a
regular .php file, which also would include whatever you're using for your
templates. In other words, they can interact just fine; you just can't put
the template upstream from a .phpp file in the include stack-- which,
again, you really shouldn't be doing, anyway, as it's just bad architecture.

How is this bad architecture? Every framework I've seen that has some
kind of templating layer that handles the scope and inclusion of the
template, and it happens further down the chain from the controlling code.

Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
otherwise they wouldn't be able to render the templates.

In the case of Zend Framwork, which I'm most familiar with, the
application, front controller, dispatcher, and action controllers, and some
services would have to remain as .php so that templates could be executed.

Oh, and the autoloader can't be .phpp either. But then if it's .php, then
the autoloader can't be called from .phpp files to include .php files.

Cheers,
David

It's been awhile since I've used Smarty, but unless my memory is failing
me, I'm pretty sure it's not restricted to being several points removed
upstream as you described. I'm not familiar with Zend_View or Twig so I
can't comment on those.

Thing is, there's no reason why you can't hook any framework into this.
Worst-case scenario, if the library you're hooking into has a rigid
structure, just write a simple controller class layer to operate on top of
it, then use that same controller class to interface with the .phpp stack.
Problem solved. It's really not as complicated or confusing as you're
making it out to be.

--Kris

Both Smarty and Twig compile your template files down to php templates.
Zend_View, Aura.View, and Symfony's php view include php files directly
without a compilation phase.

I don't get how I would write a "simple controller class layer to operate
on top of it".

Does the inclusion limitation apply to just the script in question, or the
entire call stack?

A simplified example:
index.php -> FrontController.phpp -> Controller.phpp -> View.phpp -> can't
include template.phtml

index.php -> FrontController.phpp -> Controller.phpp -> View.php -> can
include template.phtml ?
But I can't do require_once('View.php') in the controller.

If there's an autoloader involved, it would have to be set up in
index.php, and would also have to be .php so that it can include both file
types.

index.php -> FrontController.phpp -> Controller.phpp -> Autoloader.php ->
can include View.php ?

But will that work since there are .phpp files above it in the call stack?

Cheers,
David

I'm sorry, I was vague on this point in my previous response. The
controller script would be standard .php, not .phpp. And rather than a
one-dimensional linear progression, there would be parallel stacks, one
.php and the other .phpp, both coming together in the controller (which is
.php).

If I get some time this weekend I'll try to throw together a working
example. Perhaps that'll help clarify my thinking on this. =)

--Kris

13 years ago by Kris Craig — view source

unread

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less PHP
scripts.

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

This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to locate
under docroot?
It relates previous question. How about bootstrap script for frameworks?

I'm not sure what the best SAPI configuration would be, but if I had to
throw out an educated guess, I'd say the .phpp extension would just go
through a separate handler. All the code in the file would then be parsed
as PHP, with the added error conditions as described in the RFC. So I
don't anticipate there being any problems once the webserver has been
configured to recognize the new file extension. The files can be included
or accessed directly via HTTP (though in most cases I wouldn't recommend
that from an architectural standpoint, AJAX notwithstanding of course).

A regular .php script cannot be included from a .phpp script. An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will be
thrown for require; in both instances, the included file will be ignored.

Some people may try to make .phpp handled by web.

Though not necessarily required, my thinking is that that should be ok, so
long as the webserver is configured to know what to do with it of course.
It's conceivable that certain AJAX calls might want to take advantage of
pure scripts, for example.

I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?

I see no reason why it should be. Embedded PHP will still be there exactly
as it is now; the .php file extension will not be changed by this RFC
whatsoever. As far as whether people will continue using embedded PHP, I
have no idea and I'm guessing there'd probably strong opinions on both
sides of that. This RFC doesn't attempt to address that question, though.
The future of embedded PHP is a separate topic entirely. But my gut
feeling is, so long as there are developers who continue to want it, it'll
still be there for them.

It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

13 years ago by Yasuo Ohgaki — view source

unread

Hi,

If we aren't going to consider saving current code risk, then
we could use both new include and file name convention.

Introduce application/x-httpd-php-script, then we could

AddHandler php5-script .php
AddType text/html .php
AddType application/x-httpd-php-source .phps
AddType application/x-httpd-php-script .ph // .phpp .phpc .phpscript
whatever extension here

We may need ENV vars for other SAPIs.

script/script_once for PHP only script includes.

How about this?

--
Yasuo Ohgaki
yohgaki@ohgaki.net

13 years ago by Kris Craig — view source

unread

Hi,

If we aren't going to consider saving current code risk, then
we could use both new include and file name convention.

Introduce application/x-httpd-php-script, then we could

AddHandler php5-script .php
AddType text/html .php
AddType application/x-httpd-php-source .phps
AddType application/x-httpd-php-script .ph // .phpp .phpc .phpscript
whatever extension here

Yeah that's more or less what I had in mind, actually. There'd be work
involved, no question, but there's no reason why it shouldn't be doable.

We may need ENV vars for other SAPIs.

I'm only familiar with installing PHP on Apache and IIS, so I honestly have
no idea how it would work with other webservers. I'd wager that it's
possible enough, but as for the "how," I'll have to defer to those who have
experience working with said webserver(s).

script/script_once for PHP only script includes.

Would the new "script" keyword behave like include or require? I'm very
wary of the idea of having a special include to treat .php files the same
as .phpp files, simply because it would seem to add a lot of complexity and
potential for confusion, but I won't necessarily rule it out altogether,
either. Right now I'm just working on reassuring those who are afraid this
will cause every single framework on the internet to spontaneously combust
lol.

How about this?

--
Yasuo Ohgaki
yohgaki@ohgaki.net

13 years ago by Yasuo Ohgaki — view source

unread

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Hi,

If we aren't going to consider saving current code risk, then
we could use both new include and file name convention.

Introduce application/x-httpd-php-script, then we could

AddHandler php5-script .php
AddType text/html .php
AddType application/x-httpd-php-source .phps
AddType application/x-httpd-php-script .ph // .phpp .phpc .phpscript
whatever extension here

Yeah that's more or less what I had in mind, actually. There'd be work
involved, no question, but there's no reason why it shouldn't be doable.

We may need ENV vars for other SAPIs.

I'm only familiar with installing PHP on Apache and IIS, so I honestly have
no idea how it would work with other webservers. I'd wager that it's
possible enough, but as for the "how," I'll have to defer to those who have
experience working with said webserver(s).

script/script_once for PHP only script includes.

Would the new "script" keyword behave like include or require? I'm very
wary of the idea of having a special include to treat .php files the same as
.phpp files, simply because it would seem to add a lot of complexity and
potential for confusion, but I won't necessarily rule it out altogether,
either. Right now I'm just working on reassuring those who are afraid this
will cause every single framework on the internet to spontaneously combust
lol.

Will it?

As I wrote in other thread, it convenient for backward
compatibility.

function script($file) { return include($file); }
function script_once($file) { return include_once($file); }

It's for new PHP. Why not new keyword.

It's true that people are used file extension convention.
application/x-httpd-php-script and script/script_once for script
only PHP may confuse people. I think it is acceptable, but others
may not.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

13 years ago by Yasuo Ohgaki — view source

unread

2012/4/13 Yasuo Ohgaki yohgaki@ohgaki.net:

Hi,

If we aren't going to consider saving current code risk, then
we could use both new include and file name convention.

Introduce application/x-httpd-php-script, then we could

AddHandler php5-script .php
AddType text/html .php
AddType application/x-httpd-php-source .phps
AddType application/x-httpd-php-script .ph // .phpp .phpc .phpscript
whatever extension here

We may need ENV vars for other SAPIs.

script/script_once for PHP only script includes.

How about this?

Forgot to mention CLI.
CLI switch for script only should be included.
Putting all 3 RFC together may work as long as
basic semantics is the same.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

13 years ago by John LeSueur — view source

unread

On Thu, Apr 12, 2012 at 7:51 PM, John LeSueur john.lesueur@gmail.comwrote:

On Thu, Apr 12, 2012 at 6:35 PM, David Muir davidkmuir@gmail.com
wrote:

On Thu, Apr 12, 2012 at 5:46 PM, David Muir davidkmuir@gmail.com
wrote:

On Thu, Apr 12, 2012 at 4:46 PM, David Muir davidkmuir@gmail.com
wrote:

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This
proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less
PHP
scripts.

https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or
else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to
locate
under docroot?
It relates previous question. How about bootstrap script for
frameworks?

A regular .php script cannot be included from a .phpp script. An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR will
be
thrown for require; in both instances, the included file will be
ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

That's a huge WTF that a templating library can't be written as
.phpp,
because it then won't be able to load a template.

That's actually not true. Please refer to the diagram embedded in the
RFC.

Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway. The
.phpp file is, at least for the most part, intended to be included
from a
regular .php file, which also would include whatever you're using for
your
templates. In other words, they can interact just fine; you just
can't put
the template upstream from a .phpp file in the include stack-- which,
again, you really shouldn't be doing, anyway, as it's just bad
architecture.

How is this bad architecture? Every framework I've seen that has some
kind of templating layer that handles the scope and inclusion of the
template, and it happens further down the chain from the controlling
code.

Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
otherwise they wouldn't be able to render the templates.

In the case of Zend Framwork, which I'm most familiar with, the
application, front controller, dispatcher, and action controllers,
and some
services would have to remain as .php so that templates could be
executed.

Oh, and the autoloader can't be .phpp either. But then if it's .php,
then
the autoloader can't be called from .phpp files to include .php files.

Cheers,
David

It's been awhile since I've used Smarty, but unless my memory is
failing
me, I'm pretty sure it's not restricted to being several points removed
upstream as you described. I'm not familiar with Zend_View or Twig so
I
can't comment on those.

Thing is, there's no reason why you can't hook any framework into this.
Worst-case scenario, if the library you're hooking into has a rigid
structure, just write a simple controller class layer to operate on
top of
it, then use that same controller class to interface with the .phpp
stack.
Problem solved. It's really not as complicated or confusing as you're
making it out to be.

--Kris

Both Smarty and Twig compile your template files down to php templates.
Zend_View, Aura.View, and Symfony's php view include php files directly
without a compilation phase.

I don't get how I would write a "simple controller class layer to
operate
on top of it".

Does the inclusion limitation apply to just the script in question, or
the
entire call stack?

A simplified example:
index.php -> FrontController.phpp -> Controller.phpp -> View.phpp ->
can't
include template.phtml

index.php -> FrontController.phpp -> Controller.phpp -> View.php -> can
include template.phtml ?
But I can't do require_once('View.php') in the controller.

If there's an autoloader involved, it would have to be set up in
index.php, and would also have to be .php so that it can include both
file
types.

index.php -> FrontController.phpp -> Controller.phpp -> Autoloader.php
->
can include View.php ?

But will that work since there are .phpp files above it in the call
stack?

Cheers,
David

I'm sorry, I was vague on this point in my previous response. The
controller script would be standard .php, not .phpp. And rather than a
one-dimensional linear progression, there would be parallel stacks, one
.php and the other .phpp, both coming together in the controller (which
is
.php).

If I get some time this weekend I'll try to throw together a working
example. Perhaps that'll help clarify my thinking on this. =)

--Kris

I missed replying to the list here, sorry!

John LeSueur wrote:

I'm -1 on this, since the main benefit of .phpp is for class/library
files. This handles models just fine, but controllers who include .php
files for templating won't be able to take advantage. Also, any templating
library will have to be written with .php. Smarty, Twig, etc. use class
files just as much as any model or controller, and have just as much reason
to use .phpp.

Kris Craig Wrote:
As I said, this is simply not true. Controllers that include .php files
for templating would still be able to include .phpp files and thus take
full advantage. Again, I would strongly encourage you to review the
diagram posted on the RFC.

But controllers can't be in a .phpp file, even when they are pure php. Take
the following:

//a controller, maybe a class, maybe just a set of functions, but in a
.phpp file
function getLoginPage()
{
//set up some data
//some people like to use plain .php for templates
include 'templates/loginPage.php';
//other people like to use a View library
$view->render('loginPage.tpl');
}

In the case of using a view object, your controller can be a .phpp file. In
the case of the include, it cannot. Now consider the case of the
implementation of the render() method:

function render($template)
{
$compiledTemplate = $this->compile($template);
include $compiledTemplate;
}

Now your render method cannot be in a .phpp file.

What exactly is the benefit of this kind of segregation? why would a
.phpp file care that no other files included after it are .php?

Simple: It's a lot easier to hire a designer and a programmer than it is
to hire two people who are each fluent in both design and programming. In
other words, on complex projects with intense graphical and functionality
requirements, being able to separate the development process into design
and scripting components, without merge conflicts between the two, is far
more efficient and economical. That's why familiarity with the MVC
standard is listed as a requirement on many (if not most) developer job
postings nowadays.

If you have .phpp files, the designer immediately knows to steer clear.
Likewise, it means that the PHP developer can build the model with
impunity because he knows it won't collide with the work that the designer
is doing on the templating layer. The controller is the point where the
two meet, and that would be a .php file which includes both .php and .phpp
files, thus allowing full cooperation and interaction between the two while
simultaneously segregating their roles.

Yes, the segregation provided by MVC is great. I'm not questioning that.
I'm asking about the segregation of include trees of .phpp(code) files from
include trees of .php(template) files. They're already going to be
separated in the filesystem(in any sane application), so designers won't be
looking at .phpp files(and in some cases, may not have access to that
portion of the code tree). I just don't agree that the engine also needs to
create segregated include trees in order to facilitate MVC. There's a lot
of ways to do the V in MVC, and a lot of ways to connect the C to it. It
seems like this RFC puts restrictions on those in an unnecessary way. I'm
not sure we're going to agree on this point(as you said somewhere else,
smart people disagree all the time), but I wanted to make my objections
clear.

John

13 years ago by Kris Craig — view source

unread

On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur john.lesueur@gmail.comwrote:

On Thu, Apr 12, 2012 at 7:51 PM, John LeSueur john.lesueur@gmail.comwrote:

On Thu, Apr 12, 2012 at 7:49 PM, Kris Craig kris.craig@gmail.comwrote:

On Thu, Apr 12, 2012 at 6:35 PM, David Muir davidkmuir@gmail.com
wrote:

On Thu, Apr 12, 2012 at 5:46 PM, David Muir davidkmuir@gmail.com
wrote:

On Thu, Apr 12, 2012 at 4:46 PM, David Muir davidkmuir@gmail.com
wrote:

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This
proposal
offers what I believe to be a more sane and realistic approach to
addressing the question of incorporating a new breed of tag-less
PHP
scripts.

https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php or
else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to
locate
under docroot?
It relates previous question. How about bootstrap script for
frameworks?

A regular .php script cannot be included from a .phpp script. An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR
will be
thrown for require; in both instances, the included file will be
ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

That's a huge WTF that a templating library can't be written as
.phpp,
because it then won't be able to load a template.

That's actually not true. Please refer to the diagram embedded in
the
RFC.

Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway.
The
.phpp file is, at least for the most part, intended to be included
from a
regular .php file, which also would include whatever you're using
for your
templates. In other words, they can interact just fine; you just
can't put
the template upstream from a .phpp file in the include stack-- which,
again, you really shouldn't be doing, anyway, as it's just bad
architecture.

How is this bad architecture? Every framework I've seen that has
some
kind of templating layer that handles the scope and inclusion of the
template, and it happens further down the chain from the controlling
code.

Zend_View, Twig or Smarty would have to remain as .php and not .phpp,
otherwise they wouldn't be able to render the templates.

In the case of Zend Framwork, which I'm most familiar with, the
application, front controller, dispatcher, and action controllers,
and some
services would have to remain as .php so that templates could be
executed.

Oh, and the autoloader can't be .phpp either. But then if it's .php,
then
the autoloader can't be called from .phpp files to include .php
files.

Cheers,
David

It's been awhile since I've used Smarty, but unless my memory is
failing
me, I'm pretty sure it's not restricted to being several points
removed
upstream as you described. I'm not familiar with Zend_View or Twig
so I
can't comment on those.

Thing is, there's no reason why you can't hook any framework into
this.
Worst-case scenario, if the library you're hooking into has a rigid
structure, just write a simple controller class layer to operate on
top of
it, then use that same controller class to interface with the .phpp
stack.
Problem solved. It's really not as complicated or confusing as you're
making it out to be.

--Kris

Both Smarty and Twig compile your template files down to php
templates.
Zend_View, Aura.View, and Symfony's php view include php files
directly
without a compilation phase.

I don't get how I would write a "simple controller class layer to
operate
on top of it".

Does the inclusion limitation apply to just the script in question,
or the
entire call stack?

A simplified example:
index.php -> FrontController.phpp -> Controller.phpp -> View.phpp ->
can't
include template.phtml

index.php -> FrontController.phpp -> Controller.phpp -> View.php ->
can
include template.phtml ?
But I can't do require_once('View.php') in the controller.

If there's an autoloader involved, it would have to be set up in
index.php, and would also have to be .php so that it can include both
file
types.

index.php -> FrontController.phpp -> Controller.phpp ->
Autoloader.php ->
can include View.php ?

But will that work since there are .phpp files above it in the call
stack?

Cheers,
David

I'm sorry, I was vague on this point in my previous response. The
controller script would be standard .php, not .phpp. And rather than a
one-dimensional linear progression, there would be parallel stacks, one
.php and the other .phpp, both coming together in the controller (which
is
.php).

If I get some time this weekend I'll try to throw together a working
example. Perhaps that'll help clarify my thinking on this. =)

--Kris

I missed replying to the list here, sorry!

John LeSueur wrote:

I'm -1 on this, since the main benefit of .phpp is for class/library
files. This handles models just fine, but controllers who include .php
files for templating won't be able to take advantage. Also, any templating
library will have to be written with .php. Smarty, Twig, etc. use class
files just as much as any model or controller, and have just as much reason
to use .phpp.

Kris Craig Wrote:
As I said, this is simply not true. Controllers that include .php files
for templating would still be able to include .phpp files and thus take
full advantage. Again, I would strongly encourage you to review the
diagram posted on the RFC.

But controllers can't be in a .phpp file, even when they are pure php.
Take the following:

Again, I'm not saying that they should be. The controller is a .php file,
not a .phpp file.

//a controller, maybe a class, maybe just a set of functions, but in a
.phpp file
function getLoginPage()
{
//set up some data
//some people like to use plain .php for templates
include 'templates/loginPage.php';
//other people like to use a View library
$view->render('loginPage.tpl');
}

In the case of using a view object, your controller can be a .phpp file.
In the case of the include, it cannot. Now consider the case of the
implementation of the render() method:

function render($template)
{
$compiledTemplate = $this->compile($template);
include $compiledTemplate;
}

Now your render method cannot be in a .phpp file.

Again, the controller should NOT be a .phpp file. Likewise, your model
should NOT be hooking directly to the view. The controller hooks to the
model. The controller then sanitizes that and returns it to the view.
Alternatively, if you're not conforming to a pure MVC standard, the
controller can also hook to a regular .php file in the model and pass the
data to that. Either way, it all passes through the controller. The model
and view should never be interacting directly. MVC or not, that's just bad
architecture and there are zero advantages to using such an ad hoc approach.

If a developer insists on using such a broken model, however, they're more
than welcome to! That's what people love (and hate) about PHP. It's
flexible. They just won't be able to use a .phpp file upstream from that,
as it is by its very nature inherently incompatible with such a broken
model. The only way to force it to be compatible would be to make the
.phpp file essentially meaningless.

So if you're writing good code structure, a .phpp file will help you make
it even better. If you're writing bad architecture, then just keep doing
what you're already doing and don't worry about using a .phpp file! This
will in no way stop you from being able to do what you can already do in
PHP. You're just insisting on wanting to use a pure code file for
something that it's not intended to be used for. Just like having object
orientation added in PHP 5 didn't stop you from writing procedural code if
you want to, introducing this in PHP 6 won't stop you from writing
disorganized code if you still want to. What this will do is provide a
valuable option for people who do feel that writing clean, role-segregated
code is important.

What exactly is the benefit of this kind of segregation? why would a
.phpp file care that no other files included after it are .php?

Simple: It's a lot easier to hire a designer and a programmer than it is
to hire two people who are each fluent in both design and programming. In
other words, on complex projects with intense graphical and functionality
requirements, being able to separate the development process into design
and scripting components, without merge conflicts between the two, is far
more efficient and economical. That's why familiarity with the MVC
standard is listed as a requirement on many (if not most) developer job
postings nowadays.

If you have .phpp files, the designer immediately knows to steer clear.
Likewise, it means that the PHP developer can build the model with
impunity because he knows it won't collide with the work that the designer
is doing on the templating layer. The controller is the point where the
two meet, and that would be a .php file which includes both .php and .phpp
files, thus allowing full cooperation and interaction between the two while
simultaneously segregating their roles.

Yes, the segregation provided by MVC is great. I'm not questioning that.
I'm asking about the segregation of include trees of .phpp(code) files from
include trees of .php(template) files. They're already going to be
separated in the filesystem(in any sane application), so designers won't be
looking at .phpp files(and in some cases, may not have access to that
portion of the code tree). I just don't agree that the engine also needs to
create segregated include trees in order to facilitate MVC. There's a lot
of ways to do the V in MVC, and a lot of ways to connect the C to it. It
seems like this RFC puts restrictions on those in an unnecessary way. I'm
not sure we're going to agree on this point(as you said somewhere else,
smart people disagree all the time), but I wanted to make my objections
clear.

When I say they need to be segregated, what I'm referring to is model code
being separated from template code. There is never a valid reason for the
two to interact directly without going through an intermediary (i.e. a
controller). If your code does, ok. Using a .phpp file in that project
probably wouldn't be the best option for you. Either way, your existing
code will continue to work just as it does now. There's no rule saying you
HAVE to convert your code to MVC, after all. This RFC merely provides
support for that, which I believe is warranted given its wide usage and the
significant advantages it would bring to facilitating that.

Regarding your rendering example, you could make it work by simply
structuring it like so:

frontend.view.php:

<?php

require( "controller.class.php" );
$controller = new Controller();
print $controller->render( "MyTemplate" );

controller.class.php:

<?php

class Controller
{
// Constructor, methods, etc.... Pretend they're all here, including
dispatch, etc.

 public function render( $template )
 {
      // Insert whatever code here.

      // Process some variables used by the template for whatever

reason.
require_once( "model.class.phpp" );

      $model = new Model( $whatever );
      $this->templatevars = $model->calculate_quantum_particle_density(

$somevar, TRUE, 42, "Alan Alda" );

      // Now get the template and pass the template vars array to it.
      require_once( "templates.view.class.php" );

      $templates = new Templates();
      $html = $templates->load( $template );

      return $model->parse_hypothetical_templatescript( $html,

$this->templatevars );
}
}

I think the point has been made so I'll refrain from conjuring fake model
and template scripts. As you can see, the .phpp and .php code are
interacting perfectly. Of course, it obviously wouldn't make any sense to
have raw HTML code in the template load function since the frontend viewer
is handling that, plus I'd probably have put the variable parsing stuff in
the template class as well but I put it in the model just to illustrate the
point.

If, for some stupid-ass reason, Templates::load() executed over a section
of ?> HTML code, no error would be thrown (it would just look really,
REALLY stupid lol). Why? Because the controller is a .php file, NOT a
.phpp file. As such, it does exactly what a controller should do;
facilitate interaction between the model and view entry points.

Now, if your code has a completely incompatible architecture that has ?>
stuff mixed in all over the place in the stack, then a .phpp file really
isn't appropriate for that project, anyway. But if you do have a clean
separation, then this will enable you to write all the scripts in your
model layer in pure PHP code without having to worry about <?php tags or ?>
HTML crap getting inadvertently mixed-in. If it works for you, use it. If
it doesn't, just keep doing what you're doing.

Make sense?

--Kris

P.S. Don't bother pointing out flaws in the example code I created above.
It's just pseudo-code that I threw together to demonstrate how the .php
and .phpp code are able to interact via the controller, nothing more. ;)

John

13 years ago by David Muir — view source

unread

Again, the controller should NOT be a .phpp file. Likewise, your model
should NOT be hooking directly to the view. The controller hooks to the
model. The controller then sanitizes that and returns it to the view.
Alternatively, if you're not conforming to a pure MVC standard, the
controller can also hook to a regular .php file in the model and pass the
data to that. Either way, it all passes through the controller. The model
and view should never be interacting directly. MVC or not, that's just bad
architecture and there are zero advantages to using such an ad hoc approach.

If a developer insists on using such a broken model, however, they're more

MVC is a broken model/bad architecture?

than welcome to! That's what people love (and hate) about PHP. It's
flexible. They just won't be able to use a .phpp file upstream from that,
as it is by its very nature inherently incompatible with such a broken
model. The only way to force it to be compatible would be to make the
.phpp file essentially meaningless.

So if you're writing good code structure, a .phpp file will help you make
it even better. If you're writing bad architecture, then just keep doing
what you're already doing and don't worry about using a .phpp file! This
will in no way stop you from being able to do what you can already do in
PHP. You're just insisting on wanting to use a pure code file for
something that it's not intended to be used for. Just like having object
orientation added in PHP 5 didn't stop you from writing procedural code if
you want to, introducing this in PHP 6 won't stop you from writing
disorganized code if you still want to. What this will do is provide a
valuable option for people who do feel that writing clean, role-segregated
code is important.

So basically, the only parts that might be ok to write as .phpp are some
model and utility classes?

David

13 years ago by Kris Craig — view source

unread

Again, the controller should NOT be a .phpp file. Likewise, your model
should NOT be hooking directly to the view. The controller hooks to the
model. The controller then sanitizes that and returns it to the view.
Alternatively, if you're not conforming to a pure MVC standard, the
controller can also hook to a regular .php file in the model and pass the
data to that. Either way, it all passes through the controller. The
model
and view should never be interacting directly. MVC or not, that's just
bad
architecture and there are zero advantages to using such an ad hoc
approach.

If a developer insists on using such a broken model, however, they're
more

MVC is a broken model/bad architecture?

Arrooo? Not sure where you got that from, as it's basically the exact
opposite of what I said....

than welcome to! That's what people love (and hate) about PHP. It's
flexible. They just won't be able to use a .phpp file upstream from
that,
as it is by its very nature inherently incompatible with such a broken
model. The only way to force it to be compatible would be to make the
.phpp file essentially meaningless.

So if you're writing good code structure, a .phpp file will help you make
it even better. If you're writing bad architecture, then just keep doing
what you're already doing and don't worry about using a .phpp file! This
will in no way stop you from being able to do what you can already do in
PHP. You're just insisting on wanting to use a pure code file for
something that it's not intended to be used for. Just like having object
orientation added in PHP 5 didn't stop you from writing procedural code
if
you want to, introducing this in PHP 6 won't stop you from writing
disorganized code if you still want to. What this will do is provide a
valuable option for people who do feel that writing clean,
role-segregated
code is important.

So basically, the only parts that might be ok to write as .phpp are some
model and utility classes?

Essentially, yes. Despite your implication, often times these components
make up the vast majority of a modern PHP application.

David

13 years ago by David Muir — view source

unread

On Thu, Apr 12, 2012 at 11:37 PM, David Muir <davidkmuir@gmail.com
mailto:davidkmuir@gmail.com> wrote:

> Again, the controller should NOT be a .phpp file.  Likewise,
your model
> should NOT be hooking directly to the view.  The controller
hooks to the
> model.  The controller then sanitizes that and returns it to the
view.
>  Alternatively, if you're not conforming to a pure MVC standard, the
> controller can also hook to a regular .php file in the model and
pass the
> data to that.  Either way, it all passes through the controller.
 The model
> and view should never be interacting directly.  MVC or not,
that's just bad
> architecture and there are zero advantages to using such an ad
hoc approach.
>
> If a developer insists on using such a broken model, however,
they're more

MVC is a broken model/bad architecture?

Arrooo? Not sure where you got /that/ from, as it's basically the
exact opposite of what I said....

That was me being snarky. I understood what you were trying to say, but
you were trumpeting the superiority of MVC, while deriding architecture
that conforms to common MVC patterns.

> than welcome to!  That's what people love (and hate) about PHP.
 It's
> flexible.  They just won't be able to use a .phpp file upstream
from that,
> as it is by its very nature inherently incompatible with such a
broken
> model.  The only way to force it to be compatible would be to
make the
> .phpp file essentially meaningless.
>
> So if you're writing good code structure, a .phpp file will help
you make
> it even better.  If you're writing bad architecture, then just
keep doing
> what you're already doing and don't worry about using a .phpp
file!  This
> will in no way stop you from being able to do what you can
already do in
> PHP.  You're just insisting on wanting to use a pure code file for
> something that it's not intended to be used for.  Just like
having object
> orientation added in PHP 5 didn't stop you from writing
procedural code if
> you want to, introducing this in PHP 6 won't stop you from writing
> disorganized code if you still want to.  What this will do is
provide a
> valuable option for people who do feel that writing clean,
role-segregated
> code is important.

So basically, the only parts that might be ok to write as .phpp
are some
model and utility classes?

Essentially, yes. Despite your implication, often times these
components make up the vast majority of a modern PHP application.

It's also the portion that is typically not provided by frameworks and
libraries. If you're extending or implementing anything from those
libraries, and they're provided as .php (as most things would be), then
you won't be able to use them in your .phpp classes (unless you
explicitly include them from a .php file further up the chain). You end
up losing a lot of flexibility, with no perceivable gain.

Cheers,
David

13 years ago by Kris Craig — view source

unread

Again, the controller should NOT be a .phpp file. Likewise, your model
should NOT be hooking directly to the view. The controller hooks to the
model. The controller then sanitizes that and returns it to the view.
Alternatively, if you're not conforming to a pure MVC standard, the
controller can also hook to a regular .php file in the model and pass
the
data to that. Either way, it all passes through the controller. The
model
and view should never be interacting directly. MVC or not, that's just
bad
architecture and there are zero advantages to using such an ad hoc
approach.

If a developer insists on using such a broken model, however, they're
more

MVC is a broken model/bad architecture?

Arrooo? Not sure where you got that from, as it's basically the exact
opposite of what I said....

That was me being snarky. I understood what you were trying to say, but
you were trumpeting the superiority of MVC, while deriding architecture
that conforms to common MVC patterns.

than welcome to! That's what people love (and hate) about PHP. It's
flexible. They just won't be able to use a .phpp file upstream from
that,
as it is by its very nature inherently incompatible with such a broken
model. The only way to force it to be compatible would be to make the
.phpp file essentially meaningless.

So if you're writing good code structure, a .phpp file will help you
make
it even better. If you're writing bad architecture, then just keep
doing
what you're already doing and don't worry about using a .phpp file!
This
will in no way stop you from being able to do what you can already do in
PHP. You're just insisting on wanting to use a pure code file for
something that it's not intended to be used for. Just like having
object
orientation added in PHP 5 didn't stop you from writing procedural code
if
you want to, introducing this in PHP 6 won't stop you from writing
disorganized code if you still want to. What this will do is provide a
valuable option for people who do feel that writing clean,
role-segregated
code is important.

So basically, the only parts that might be ok to write as .phpp are some
model and utility classes?

Essentially, yes. Despite your implication, often times these components
make up the vast majority of a modern PHP application.

It's also the portion that is typically not provided by frameworks and
libraries. If you're extending or implementing anything from those
libraries, and they're provided as .php (as most things would be), then you
won't be able to use them in your .phpp classes (unless you explicitly
include them from a .php file further up the chain). You end up losing a
lot of flexibility, with no perceivable gain.

The gain has been described by myself and others quite a bit already. As
far as I can tell, the fact that some frameworks/libraries wouldn't be
compatible with this doesn't negate the unrelated advantages that do exist.
Worst-case scenario, you just wouldn't use this with those frameworks.

But again, before we jump down that rabbit hole again, please refer to
recent suggestions that have been made regarding that; i.e. a third type
for per-file instead of per-stack checking. While I see no more value in
per-file checking than you do in per-stack, it would alleviate your
concerns regarding certain frameworks and libraries.

--Kris

Cheers,
David

13 years ago by Ferenc Kovacs — view source

unread

The gain has been described by myself and others quite a bit already. As
far as I can tell, the fact that some frameworks/libraries wouldn't be
compatible with this doesn't negate the unrelated advantages that do exist.
Worst-case scenario, you just wouldn't use this with those frameworks.

usually we tend to accept changes only if the pros remarkably overweight
the cons.
introducing a new language construct which target audience is just a small
percentage of the potential userbase seems to have a hard time getting
accepted.
(annotations was an example of this, even thought that the syntax was
thought out, and it was/is already used in the wild (Doctrine2, Symfony2)
the majority of the voters seemed to be against it)

of course you can succeed where others failed, but I think it would greatly
increase the chances if:
1, the intention of the change is clearly laid out, and easily understood
via reading the RFC
2, the change would make some useful real-life scenario possible or
significantly easier
3, the change would make the least impact on the pre-existing code(minimal
required BC impact)
4, the change is in line with the "PHP way".

I think that the current proposals are lacking in those aspects.

but to go back to your proposal:
I think that it would be nice, if you could update the RFC based on the
discussion, as it will be harder and harder to join the discussion, if one
has to read the RFC then read all of the related discussion (scattered
through many threads) in the correct order to be able to catch up with the
current status.
you mentioned that some ideas or alternatives was presented but you didn't
wanted to incorporate those, until you finish sorting those out in the
mailing list and consensus is reached.
which is a good idea at first, but if/when the discussion is
abadoned/derailed/etc. then there it is a good chance, that the original
idea is lost too.
I really liked the https://wiki.php.net/rfc/closures/object-extension in
this regard (even though that in the end that was also abandoned so it
isn't consistent with the actual implementation).
It describes the ideas which were presented, compares the pros/cons, etc. I
really liked that.
So I would suggest you to update you RFC accordingly (and while I think
that the separate nophptags RFCs should be kept separate, but mentioning
what deviates yours from the other two could be a good idea too).

"Over the years, people have occasionally called for one of a few
fundamental changes"
would be nice if you could link those calls if you have them, maybe they
have some arguments that we didn't see yet (or maybe we could see that some
of those are PEBKAC)

"There will be no BC breaks."
depending on the implementation (making the SAPIs aware of the new file
extension or the parser to the new <?phpsomething tag) there is a small
chance that somebody already using that extension/tag which would turn
those files executable php scripts. ofc. it isn't that likely.

of course if we go with the <?phpsomething tag, then the many of the
current premises needs to be rewritten, and it would remove the "I can save
5 keystrokes per files" and "some random output by mistake before the
opening tag sending out junk before the opening tag" from the equitation.
you still need to have an opening tag, and you can also put something
before the tag (albeit I think that those problems would error out with
<?phpo either because the <?phpo could be only at the begining of the file,
or by an unexpected direct output in case of another phpp file including
the borked file),
so what we have left is the ability to create an arbitrary restriction so
that phpp files cannot switch to "template" mode or include files(directly
or indirectly) which would do that.

As others (and your RFC) stated, this would only cover part of the original
issue: class files spitting out direct input.
Your solution would only solve half of the problem, but in exchange you
would make the promise that under no circumstances would you try to include
any php file from your phpp file.
Which can be a really hard thing to promise upfront:

if you have file includes based on some dynamic logic(the filename coming
from database for example).
if you have a global autoloader, that can cause hard-to-see dependencies.
if you have an error/exception handler, that can cause hard-to-see
dependencies.

I think it would make more sense, if we would solve the original problem:
preventing the the class files from spitting out output.
one could do something similar via ob_start-ing before the file include and
discarding the buffer or erroring out if the buffer isn't empy (albeit that
would only prevent the mistakes, not the malicious code from flushing the
buffer).
another possibility would be adding control options for the include/require
calls, so one can tell whether the included files can have output (or
allowing a variable to be passed, which will hold the generated output,
that would be really nice, as many of the php template engines have to do
ob magic already to be able to return the template output instead of
outputting it.)

ps: sorry for the wallpost, and being a little bit disorganised.

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

13 years ago by Arvids Godjuks — view source

unread

I posted the bellow text in other thread, but i should have it post here,
so i'm reposting it to this thread.

Well, it's time for me to remind about the techique many use (and some
frameworks provide it out of the box) - the application file concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes mostly
used core classes in one big file.that loads much faster and is used for
production. Any other framework has user extentions or other type of
solutions for this to speed up the application, and it makes really big
difference.
So there is a good question - how the hell in a MVC framework would i
combine my models, controllers, components and other stuff that will
definetly be as in .php so in .pphp. And not every file will be cached like
that - some will remain as distinct files even in production.

The further discussion goes the more questions there is and less answers
there are.

13 years ago by Kris Craig — view source

unread

On Sun, Apr 15, 2012 at 2:30 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

I posted the bellow text in other thread, but i should have it post here,
so i'm reposting it to this thread.

Well, it's time for me to remind about the techique many use (and some
frameworks provide it out of the box) - the application file concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes mostly
used core classes in one big file.that loads much faster and is used for
production. Any other framework has user extentions or other type of
solutions for this to speed up the application, and it makes really big
difference.
So there is a good question - how the hell in a MVC framework would i
combine my models, controllers, components and other stuff that will
definetly be as in .php so in .pphp. And not every file will be cached like
that - some will remain as distinct files even in production.

The further discussion goes the more questions there is and less answers
there are.

My response is in the other thread. But you're right, we should move the
discussion back here, so please post your reply here. Thanks!

--Kris

13 years ago by Arvids Godjuks — view source

unread

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

On Sun, Apr 15, 2012 at 2:30 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

I posted the bellow text in other thread, but i should have it post here,
so i'm reposting it to this thread.

Well, it's time for me to remind about the techique many use (and some
frameworks provide it out of the box) - the application file concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes mostly
used core classes in one big file.that loads much faster and is used for
production. Any other framework has user extentions or other type of
solutions for this to speed up the application, and it makes really big
difference.
So there is a good question - how the hell in a MVC framework would i
combine my models, controllers, components and other stuff that will
definetly be as in .php so in .pphp. And not every file will be cached
like
that - some will remain as distinct files even in production.

The further discussion goes the more questions there is and less answers
there are.

My response is in the other thread. But you're right, we should move the
discussion back here, so please post your reply here. Thanks!

--Kris

The Kris response from the "PHP-DEV Digest 13 Apr..." response to my mail
quoted bellow:

I'm not quite sure I understand your concern. Are you saying that the
Yii framework wouldn't work with this because .phpp files would be cached
as .php?? If that's the case, what about .phpo? Or, perhaps we should
name the extension .phpf instead, as in "PHP Framework-includable".

What I'm saying that there is a widely used optimization technique -
concatenate the project files in one big massive chunk, enable an opcode
cache and things speed up big time. Almost any mid sized and above project
ends up doing that in one or the other way. Some even do that on
per-controller basis or otherwise - but the fact is - it's out there.
I just gave an example of the popular framework that has this
out-of-the-box as a feature. And I, for one, do not understand how this
should play with your proposal, because in that state clean source code
ends up with "tainted" source code in one big chunk of machine-generated
striped-out-everything string of epic proportions witch PHP chews with
happy face and damn fast (helps with response times a lot, up to the
tenfold).

13 years ago by Kris Craig — view source

unread

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

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

On Sun, Apr 15, 2012 at 2:30 PM, Arvids Godjuks <arvids.godjuks@gmail.com

wrote:

I posted the bellow text in other thread, but i should have it post here,
so i'm reposting it to this thread.

Well, it's time for me to remind about the techique many use (and some
frameworks provide it out of the box) - the application file
concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes mostly
used core classes in one big file.that loads much faster and is used for
production. Any other framework has user extentions or other type of
solutions for this to speed up the application, and it makes really big
difference.
So there is a good question - how the hell in a MVC framework would i
combine my models, controllers, components and other stuff that will
definetly be as in .php so in .pphp. And not every file will be cached
like
that - some will remain as distinct files even in production.

The further discussion goes the more questions there is and less answers
there are.

My response is in the other thread. But you're right, we should move the
discussion back here, so please post your reply here. Thanks!

--Kris

The Kris response from the "PHP-DEV Digest 13 Apr..." response to my mail
quoted bellow:

I'm not quite sure I understand your concern. Are you saying that the
Yii framework wouldn't work with this because .phpp files would be cached
as .php?? If that's the case, what about .phpo? Or, perhaps we should
name the extension .phpf instead, as in "PHP Framework-includable".

What I'm saying that there is a widely used optimization technique -
concatenate the project files in one big massive chunk, enable an opcode
cache and things speed up big time. Almost any mid sized and above project
ends up doing that in one or the other way. Some even do that on
per-controller basis or otherwise - but the fact is - it's out there.
I just gave an example of the popular framework that has this
out-of-the-box as a feature. And I, for one, do not understand how this
should play with your proposal, because in that state clean source code
ends up with "tainted" source code in one big chunk of machine-generated
striped-out-everything string of epic proportions witch PHP chews with
happy face and damn fast (helps with response times a lot, up to the
tenfold).

What about the per-file approach that's been suggested? Would that work
with your framework?

The stricter per-stack approach might wind up being better suited for
projects that are created from scratch with that architecture in mind.
It's common enough that I believe there's a genuine use case for it. If
we then had a separate per-file approach designed to accommodate
frameworks/libraries that by their nature might be a bit more tangled, I
think we could get the best of both worlds with this.

--Kris

13 years ago by Arvids Godjuks — view source

unread

I should say that I do not understand in full how it suppose to work. From
the RFC it is absolutely unclear how to deal with this and the mixed code
load approach is just dismissed as invalid concern, quoting from the RFC:

Besides, such an allowance is completely unnecessary anyway, since using
non-horrible architecture can achieve the exact same result without having
to pollute your .phpp stack. Here's a screenshot from a recent Internals
thread where I illustrated this point a little more clearly:

You just dismiss a valid stack structure with the screenshot below that and
every PHP MVC framework I know of out there renders it's templates through
a controller call or invoking a template engine of some kind in the main
application and calling it's methods from controllers. Anyway the result is
obvious - you have to make a global stand-alone template engine object that
loads from index.php and not inside the application itself. I'm not
willing to think how to couple them together and the difficulties with data
passing, calling widgets and other stuff that comes along - it's just
a stretch of epic proportions to radically alter the structure with unknown
result in the end.

So, since people write a lot about that RFC is not in sync with what you
are writing, you should really update the thing. I follow the thread as
much as I could, but lets be honest - following that wall of text posted
every 4-5 minutes (while I read one mail the phone notified I received 2
more in the thread at times) was just not happening. So I'm convinced I
skipped at least a half of the discussion just being humanly unable to read
it all.
The RFC should contain the solutions for the file template inclusion, 3rd
party library inclusion,dealing with valid optimization practices and other
related stuff.

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

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

wrote:

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

On Sun, Apr 15, 2012 at 2:30 PM, Arvids Godjuks <
arvids.godjuks@gmail.com> wrote:

I posted the bellow text in other thread, but i should have it post
here,
so i'm reposting it to this thread.

Well, it's time for me to remind about the techique many use (and some
frameworks provide it out of the box) - the application file
concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes mostly
used core classes in one big file.that loads much faster and is used for
production. Any other framework has user extentions or other type of
solutions for this to speed up the application, and it makes really big
difference.
So there is a good question - how the hell in a MVC framework would i
combine my models, controllers, components and other stuff that will
definetly be as in .php so in .pphp. And not every file will be cached
like
that - some will remain as distinct files even in production.

The further discussion goes the more questions there is and less answers
there are.

My response is in the other thread. But you're right, we should move
the discussion back here, so please post your reply here. Thanks!

--Kris

The Kris response from the "PHP-DEV Digest 13 Apr..." response to my mail
quoted bellow:

I'm not quite sure I understand your concern. Are you saying that the
Yii framework wouldn't work with this because .phpp files would be cached
as .php?? If that's the case, what about .phpo? Or, perhaps we should
name the extension .phpf instead, as in "PHP Framework-includable".

What I'm saying that there is a widely used optimization technique -
concatenate the project files in one big massive chunk, enable an opcode
cache and things speed up big time. Almost any mid sized and above project
ends up doing that in one or the other way. Some even do that on
per-controller basis or otherwise - but the fact is - it's out there.
I just gave an example of the popular framework that has this
out-of-the-box as a feature. And I, for one, do not understand how this
should play with your proposal, because in that state clean source code
ends up with "tainted" source code in one big chunk of machine-generated
striped-out-everything string of epic proportions witch PHP chews with
happy face and damn fast (helps with response times a lot, up to the
tenfold).

What about the per-file approach that's been suggested? Would that work
with your framework?

The stricter per-stack approach might wind up being better suited for
projects that are created from scratch with that architecture in mind.
It's common enough that I believe there's a genuine use case for it. If
we then had a separate per-file approach designed to accommodate
frameworks/libraries that by their nature might be a bit more tangled, I
think we could get the best of both worlds with this.

--Kris

13 years ago by Kris Craig — view source

unread

The gain has been described by myself and others quite a bit already. As
far as I can tell, the fact that some frameworks/libraries wouldn't be
compatible with this doesn't negate the unrelated advantages that do
exist.
Worst-case scenario, you just wouldn't use this with those frameworks.

usually we tend to accept changes only if the pros remarkably overweight
the cons.
introducing a new language construct which target audience is just a small
percentage of the potential userbase seems to have a hard time getting
accepted.
(annotations was an example of this, even thought that the syntax was
thought out, and it was/is already used in the wild (Doctrine2, Symfony2)
the majority of the voters seemed to be against it)

of course you can succeed where others failed, but I think it would
greatly increase the chances if:
1, the intention of the change is clearly laid out, and easily understood
via reading the RFC
2, the change would make some useful real-life scenario possible or
significantly easier
3, the change would make the least impact on the pre-existing code(minimal
required BC impact)
4, the change is in line with the "PHP way".

I think that the current proposals are lacking in those aspects.

but to go back to your proposal:
I think that it would be nice, if you could update the RFC based on the
discussion, as it will be harder and harder to join the discussion, if one
has to read the RFC then read all of the related discussion (scattered
through many threads) in the correct order to be able to catch up with the
current status.
you mentioned that some ideas or alternatives was presented but you didn't
wanted to incorporate those, until you finish sorting those out in the
mailing list and consensus is reached.
which is a good idea at first, but if/when the discussion is
abadoned/derailed/etc. then there it is a good chance, that the original
idea is lost too.
I really liked the https://wiki.php.net/rfc/closures/object-extension in
this regard (even though that in the end that was also abandoned so it
isn't consistent with the actual implementation).
It describes the ideas which were presented, compares the pros/cons, etc.
I really liked that.
So I would suggest you to update you RFC accordingly (and while I think
that the separate nophptags RFCs should be kept separate, but mentioning
what deviates yours from the other two could be a good idea too).

"Over the years, people have occasionally called for one of a few
fundamental changes"
would be nice if you could link those calls if you have them, maybe they
have some arguments that we didn't see yet (or maybe we could see that some
of those are PEBKAC)

"There will be no BC breaks."
depending on the implementation (making the SAPIs aware of the new file
extension or the parser to the new <?phpsomething tag) there is a small
chance that somebody already using that extension/tag which would turn
those files executable php scripts. ofc. it isn't that likely.

of course if we go with the <?phpsomething tag, then the many of the
current premises needs to be rewritten, and it would remove the "I can save
5 keystrokes per files" and "some random output by mistake before the
opening tag sending out junk before the opening tag" from the equitation.
you still need to have an opening tag, and you can also put something
before the tag (albeit I think that those problems would error out with
<?phpo either because the <?phpo could be only at the begining of the file,
or by an unexpected direct output in case of another phpp file including
the borked file),
so what we have left is the ability to create an arbitrary restriction so
that phpp files cannot switch to "template" mode or include files(directly
or indirectly) which would do that.

As others (and your RFC) stated, this would only cover part of the
original issue: class files spitting out direct input.
Your solution would only solve half of the problem, but in exchange you
would make the promise that under no circumstances would you try to include
any php file from your phpp file.
Which can be a really hard thing to promise upfront:

if you have file includes based on some dynamic logic(the filename
coming from database for example).

if you have a global autoloader, that can cause hard-to-see dependencies.

if you have an error/exception handler, that can cause hard-to-see
dependencies.

I think it would make more sense, if we would solve the original problem:
preventing the the class files from spitting out output.
one could do something similar via ob_start-ing before the file include
and discarding the buffer or erroring out if the buffer isn't empy (albeit
that would only prevent the mistakes, not the malicious code from flushing
the buffer).
another possibility would be adding control options for the
include/require calls, so one can tell whether the included files can have
output (or allowing a variable to be passed, which will hold the generated
output, that would be really nice, as many of the php template engines have
to do ob magic already to be able to return the template output instead of
outputting it.)

ps: sorry for the wallpost, and being a little bit disorganised.

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

@Ferenc Thanks for the thoughtful analysis! I must confess I'm a bit
groggy at the moment so I'll have to go over it later. But just from my
initial skim, you're right that the RFC needs to be updated for clarity.
I'm hoping to squeeze a little bit more out of the Internals discussion
before I do so I can get some questions answered in the process.

Basically, these are my outstanding questions that I'd like to see some
more discussion about:

Should we go with a new keyword or tag? (I keep bouncing back and
forth on this one)
Would creating a third type with looser standards (i.e. allowing
regular .php to be mixed in with the stack) help alleviate the concerns
that have been expressed about usability with certain frameworks?
If we go with the keyword approach, should we create two new keywords
for each type (ugh!) or add a flag constant (bitwise?) to include and
require?

Sorry if your post already touched on any of this. My brain is really
fuzzy at the moment lol.

If we can get some good discussion and clarity on the 3 questions above,
I'd feel much more confident about updating the RFC.

--Kris

13 years ago by Ferenc Kovacs — view source

unread

@Ferenc Thanks for the thoughtful analysis! I must confess I'm a bit
groggy at the moment so I'll have to go over it later.

sure, take your time.

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

13 years ago by Arvids Godjuks — view source

unread

Kris.

I can give you a real world example where that straight MVC with the. pphp
if not breaks, then definetly becomes an ugly mess.
I use Yii framework as my tool, it has some very nice tools for templating
like widgets. Widgets provide a container to put functionalit required by
multiple pages and it contains a controller like code and a template. It
can and most times will use models and other library stuff to do its work.
And all that code is loaded via an autoloader (only templates are loaded
localy in a controller method).

As i see it, i will spend a lot of time figuring out if i need to make a
.php or a .pphp file. After a few days i will just say to my self "f***
this sh**" and just stick with the .php. My coleague will just stick with
.php - he values his time and to him this will be just noise that he
ignores because it gives no real benifit, IDE's and editors will ajust in
time and reformatting a whole project is just a waste of time. Not to
mention frameworks will not follow for a long time because of the BC and
big WTF factor.

13 years ago by Kris Craig — view source

unread

On Fri, Apr 13, 2012 at 1:00 AM, Arvids Godjuks arvids.godjuks@gmail.comwrote:

Kris.

I can give you a real world example where that straight MVC with the. pphp
if not breaks, then definetly becomes an ugly mess.
I use Yii framework as my tool, it has some very nice tools for templating
like widgets. Widgets provide a container to put functionalit required by
multiple pages and it contains a controller like code and a template. It
can and most times will use models and other library stuff to do its work.
And all that code is loaded via an autoloader (only templates are loaded
localy in a controller method).

As i see it, i will spend a lot of time figuring out if i need to make a
.php or a .pphp file. After a few days i will just say to my self "f***
this sh**" and just stick with the .php. My coleague will just stick with
.php - he values his time and to him this will be just noise that he
ignores because it gives no real benifit, IDE's and editors will ajust in
time and reformatting a whole project is just a waste of time. Not to
mention frameworks will not follow for a long time because of the BC and
big WTF factor.

As I said, if that is the case, then you shouldn't be using a .phpp file.
This new file type is NOT intended to replace .php, not even partially.
Most of your work will likely still be done in .php scripts. This new
.phpp type is for specialized instances when you know you won't be using
raw HTML output. This happens a lot, but it may not happen in your
application. If it doesn't, then don't worry about it. There's no "WTF
factor" to it and there's DEFINITELY no BC breakage, period!

If your application doesn't have a need for pure PHP code, then don't use
it. I'm not sure why you think the mere existence of this file type will
somehow magically break all your .php files.

13 years ago by John LeSueur — view source

unread

On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur john.lesueur@gmail.comwrote:

On Thu, Apr 12, 2012 at 7:51 PM, John LeSueur john.lesueur@gmail.comwrote:

On Thu, Apr 12, 2012 at 7:49 PM, Kris Craig kris.craig@gmail.comwrote:

On Thu, Apr 12, 2012 at 6:35 PM, David Muir davidkmuir@gmail.com
wrote:

On Thu, Apr 12, 2012 at 5:46 PM, David Muir davidkmuir@gmail.com
wrote:

On Thu, Apr 12, 2012 at 4:46 PM, David Muir davidkmuir@gmail.com
wrote:

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This
proposal
offers what I believe to be a more sane and realistic approach
to
addressing the question of incorporating a new breed of
tag-less PHP
scripts.

https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php
or
else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to
locate
under docroot?
It relates previous question. How about bootstrap script for
frameworks?

A regular .php script cannot be included from a .phpp script. An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR
will be
thrown for require; in both instances, the included file will be
ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

That's a huge WTF that a templating library can't be written as
.phpp,
because it then won't be able to load a template.

That's actually not true. Please refer to the diagram embedded in
the
RFC.

Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway.
The
.phpp file is, at least for the most part, intended to be included
from a
regular .php file, which also would include whatever you're using
for your
templates. In other words, they can interact just fine; you just
can't put
the template upstream from a .phpp file in the include stack--
which,
again, you really shouldn't be doing, anyway, as it's just bad
architecture.

How is this bad architecture? Every framework I've seen that has
some
kind of templating layer that handles the scope and inclusion of the
template, and it happens further down the chain from the
controlling code.

Zend_View, Twig or Smarty would have to remain as .php and not
.phpp,
otherwise they wouldn't be able to render the templates.

In the case of Zend Framwork, which I'm most familiar with, the
application, front controller, dispatcher, and action controllers,
and some
services would have to remain as .php so that templates could be
executed.

Oh, and the autoloader can't be .phpp either. But then if it's
.php, then
the autoloader can't be called from .phpp files to include .php
files.

Cheers,
David

It's been awhile since I've used Smarty, but unless my memory is
failing
me, I'm pretty sure it's not restricted to being several points
removed
upstream as you described. I'm not familiar with Zend_View or Twig
so I
can't comment on those.

Thing is, there's no reason why you can't hook any framework into
this.
Worst-case scenario, if the library you're hooking into has a rigid
structure, just write a simple controller class layer to operate on
top of
it, then use that same controller class to interface with the .phpp
stack.
Problem solved. It's really not as complicated or confusing as
you're
making it out to be.

--Kris

Both Smarty and Twig compile your template files down to php
templates.
Zend_View, Aura.View, and Symfony's php view include php files
directly
without a compilation phase.

I don't get how I would write a "simple controller class layer to
operate
on top of it".

Does the inclusion limitation apply to just the script in question,
or the
entire call stack?

A simplified example:
index.php -> FrontController.phpp -> Controller.phpp -> View.phpp ->
can't
include template.phtml

index.php -> FrontController.phpp -> Controller.phpp -> View.php ->
can
include template.phtml ?
But I can't do require_once('View.php') in the controller.

If there's an autoloader involved, it would have to be set up in
index.php, and would also have to be .php so that it can include
both file
types.

index.php -> FrontController.phpp -> Controller.phpp ->
Autoloader.php ->
can include View.php ?

But will that work since there are .phpp files above it in the call
stack?

Cheers,
David

I'm sorry, I was vague on this point in my previous response. The
controller script would be standard .php, not .phpp. And rather than a
one-dimensional linear progression, there would be parallel stacks, one
.php and the other .phpp, both coming together in the controller
(which is
.php).

If I get some time this weekend I'll try to throw together a working
example. Perhaps that'll help clarify my thinking on this. =)

--Kris

I missed replying to the list here, sorry!

John LeSueur wrote:

I'm -1 on this, since the main benefit of .phpp is for class/library
files. This handles models just fine, but controllers who include .php
files for templating won't be able to take advantage. Also, any templating
library will have to be written with .php. Smarty, Twig, etc. use class
files just as much as any model or controller, and have just as much reason
to use .phpp.

Kris Craig Wrote:
As I said, this is simply not true. Controllers that include .php files
for templating would still be able to include .phpp files and thus take
full advantage. Again, I would strongly encourage you to review the
diagram posted on the RFC.

But controllers can't be in a .phpp file, even when they are pure php.
Take the following:

Again, I'm not saying that they should be. The controller is a .php file,
not a .phpp file.

But why? it's just code, there's no html? why can't it be .phpp? Sure it
calls some function thats going to spit out html, but the file itself is
pure php, and deserves protection from accidental whitespace just as much
as any file in the model.

//a controller, maybe a class, maybe just a set of functions, but in a
.phpp file
function getLoginPage()
{
//set up some data
//some people like to use plain .php for templates
include 'templates/loginPage.php';
//other people like to use a View library
$view->render('loginPage.tpl');
}

In the case of using a view object, your controller can be a .phpp file.
In the case of the include, it cannot. Now consider the case of the
implementation of the render() method:

function render($template)
{
$compiledTemplate = $this->compile($template);
include $compiledTemplate;
}

Now your render method cannot be in a .phpp file.

Again, the controller should NOT be a .phpp file. Likewise, your model
should NOT be hooking directly to the view.

I'm not sure why you're talking about the model hooking to the view, since
I didn't mention the model at all in my example. I'm only talking about
View and Controller. I think Models will have no problem with your RFC.

The controller hooks to the model. The controller then sanitizes that and
returns it to the view. Alternatively, if you're not conforming to a pure
MVC standard, the controller can also hook to a regular .php file in the
model and pass the data to that. Either way, it all passes through the
controller. The model and view should never be interacting directly. MVC
or not, that's just bad architecture and there are zero advantages to using
such an ad hoc approach.

If a developer insists on using such a broken model, however, they're more
than welcome to! That's what people love (and hate) about PHP. It's
flexible. They just won't be able to use a .phpp file upstream from that,
as it is by its very nature inherently incompatible with such a broken
model. The only way to force it to be compatible would be to make the
.phpp file essentially meaningless.

Much as I think MVC is a great way of doing things, I don't think that
everything else is a broken model, for all applications. The PHP engine and
language really have no business encouraging one way or another. Our big
difference of opinion is that for me, .phpp is a convenience, allowing
files to avoid extraneous whitespace, while for you, .phpp is a way of
encouraging good code structure.

So if you're writing good code structure, a .phpp file will help you make
it even better. If you're writing bad architecture, then just keep doing
what you're already doing and don't worry about using a .phpp file! This
will in no way stop you from being able to do what you can already do in
PHP. You're just insisting on wanting to use a pure code file for
something that it's not intended to be used for. Just like having object
orientation added in PHP 5 didn't stop you from writing procedural code if
you want to, introducing this in PHP 6 won't stop you from writing
disorganized code if you still want to. What this will do is provide a
valuable option for people who do feel that writing clean, role-segregated
code is important.

What exactly is the benefit of this kind of segregation? why would a
.phpp file care that no other files included after it are .php?

Simple: It's a lot easier to hire a designer and a programmer than it
is to hire two people who are each fluent in both design and programming.
In other words, on complex projects with intense graphical and
functionality requirements, being able to separate the development process
into design and scripting components, without merge conflicts between the
two, is far more efficient and economical. That's why familiarity with the
MVC standard is listed as a requirement on many (if not most) developer job
postings nowadays.

If you have .phpp files, the designer immediately knows to steer clear.
Likewise, it means that the PHP developer can build the model with
impunity because he knows it won't collide with the work that the designer
is doing on the templating layer. The controller is the point where the
two meet, and that would be a .php file which includes both .php and .phpp
files, thus allowing full cooperation and interaction between the two while
simultaneously segregating their roles.

Yes, the segregation provided by MVC is great. I'm not questioning that.
I'm asking about the segregation of include trees of .phpp(code) files from
include trees of .php(template) files. They're already going to be
separated in the filesystem(in any sane application), so designers won't be
looking at .phpp files(and in some cases, may not have access to that
portion of the code tree). I just don't agree that the engine also needs to
create segregated include trees in order to facilitate MVC. There's a lot
of ways to do the V in MVC, and a lot of ways to connect the C to it. It
seems like this RFC puts restrictions on those in an unnecessary way. I'm
not sure we're going to agree on this point(as you said somewhere else,
smart people disagree all the time), but I wanted to make my objections
clear.

When I say they need to be segregated, what I'm referring to is model code
being separated from template code. There is never a valid reason for the
two to interact directly without going through an intermediary (i.e. a
controller). If your code does, ok. Using a .phpp file in that project
probably wouldn't be the best option for you. Either way, your existing
code will continue to work just as it does now. There's no rule saying you
HAVE to convert your code to MVC, after all. This RFC merely provides
support for that, which I believe is warranted given its wide usage and the
significant advantages it would bring to facilitating that.

Again, I'm not talking about Models and Views, or even how Models and
Controllers connect. I'm talking about Views and Controllers. You think
they shouldn't be allowed to be in .phpp, and I think that controllers
definitely should, and that the non-template parts of Views should as well.

Regarding your rendering example, you could make it work by simply
structuring it like so:

frontend.view.php:

<?php

require( "controller.class.php" );
$controller = new Controller();
print $controller->render( "MyTemplate" );

controller.class.php:

<?php

class Controller
{
// Constructor, methods, etc.... Pretend they're all here, including
dispatch, etc.
 public function render( $template )
 {
      // Insert whatever code here.

      // Process some variables used by the template for whatever
reason.
require_once( "model.class.phpp" );
      $model = new Model( $whatever );
      $this->templatevars =
$model->calculate_quantum_particle_density( $somevar, TRUE, 42, "Alan Alda"
);
      // Now get the template and pass the template vars array to it.
      require_once( "templates.view.class.php" );

      $templates = new Templates();
      $html = $templates->load( $template );

      return $model->parse_hypothetical_templatescript( $html,
$this->templatevars );
}
}

I think the point has been made so I'll refrain from conjuring fake model
and template scripts. As you can see, the .phpp and .php code are
interacting perfectly. Of course, it obviously wouldn't make any sense to
have raw HTML code in the template load function since the frontend viewer
is handling that, plus I'd probably have put the variable parsing stuff in
the template class as well but I put it in the model just to illustrate the
point.

If, for some stupid-ass reason, Templates::load() executed over a section
of ?> HTML code, no error would be thrown (it would just look really,
REALLY stupid lol). Why? Because the controller is a .php file, NOT a
.phpp file. As such, it does exactly what a controller should do;
facilitate interaction between the model and view entry points.

And my objection is, the controller has no ?> in it, so it is pure php. It
is just as susceptible to mistakes in whitespace as a file in the model. It
could benefit from .phpp just as much as a file in the model. It also
shouldn't be changed by designers.

Now, if your code has a completely incompatible architecture that has ?>
stuff mixed in all over the place in the stack, then a .phpp file really
isn't appropriate for that project, anyway. But if you do have a clean
separation, then this will enable you to write all the scripts in your
model layer in pure PHP code without having to worry about <?php tags or ?>
HTML crap getting inadvertently mixed-in. If it works for you, use it. If
it doesn't, just keep doing what you're doing.

But my hypothetical code stack is full of pristine code with no ?> mixed
in, except for in the templates. But I can't use .phpp on my pristine
Controller files, because they end up including .php templates.

In reality, I use a view library, so my Controller could use .phpp under
your RFC. But my view library would have to be all .php. And my view
library is a bunch of classes, with no ?> in them. But at some point, it
includes a .php template to do the actual display, so my library can't be
written in .phpp. I think that's wrong, because library code (even a view
library) needs .phpp just as much as any model.

Make sense?

I see exactly what you are saying, and I just think that using .phpp in
only 1/3(Model, but not Controller or View) of the code is restrictive. I
think that any file that doesn't have ?> should be able to take advantage
of .phpp. I see .phpp as a mode for parsing one file. It's not a paradigm
shift, just a shortcut.

John

13 years ago by Kris Craig — view source

unread

On Fri, Apr 13, 2012 at 5:45 AM, John LeSueur john.lesueur@gmail.comwrote:

On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur john.lesueur@gmail.comwrote:

On Thu, Apr 12, 2012 at 9:00 PM, Kris Craig kris.craig@gmail.comwrote:

On Thu, Apr 12, 2012 at 7:51 PM, John LeSueur john.lesueur@gmail.comwrote:

On Thu, Apr 12, 2012 at 7:49 PM, Kris Craig kris.craig@gmail.comwrote:

On Thu, Apr 12, 2012 at 6:35 PM, David Muir davidkmuir@gmail.com
wrote:

On Thu, Apr 12, 2012 at 5:46 PM, David Muir davidkmuir@gmail.com
wrote:

On Thu, Apr 12, 2012 at 4:46 PM, David Muir davidkmuir@gmail.com
wrote:

Hi,

2012/4/13 Kris Craig kris.craig@gmail.com:

Per recent discussions, I have drafted an RFC for this. This
proposal
offers what I believe to be a more sane and realistic approach
to
addressing the question of incorporating a new breed of
tag-less PHP
scripts.

https://wiki.php.net/rfc/phpp
This may work for LFI issue for new codes.
Few questions.

CLI may use .phpp as PHP script always. (i.e. execute w/o <?php
or
else)
It's like DOS, though.

How do you enforce .phpp as script only for Web?
Is it a rule for configuration? or .phpp just never supposed to
locate
under docroot?
It relates previous question. How about bootstrap script for
frameworks?

A regular .php script cannot be included from a .phpp script.
An
E_WARNING will be thrown for include and an E_RECOVERABLE_ERROR
will be
thrown for require; in both instances, the included file will be
ignored.
Some people may try to make .phpp handled by web.
I cannot tell if this setting is going to be popular, but if it
does, isn't it the end of embedded PHP?
It might be good if PHP is more tolerant for this usage.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

That's a huge WTF that a templating library can't be written as
.phpp,
because it then won't be able to load a template.

That's actually not true. Please refer to the diagram embedded in
the
RFC.

Basically, you can load a template just fine-- you just can't do it
directly from a .phpp file, which you shouldn't be doing, anyway.
The
.phpp file is, at least for the most part, intended to be included
from a
regular .php file, which also would include whatever you're using
for your
templates. In other words, they can interact just fine; you just
can't put
the template upstream from a .phpp file in the include stack--
which,
again, you really shouldn't be doing, anyway, as it's just bad
architecture.

How is this bad architecture? Every framework I've seen that has
some
kind of templating layer that handles the scope and inclusion of
the
template, and it happens further down the chain from the
controlling code.

Zend_View, Twig or Smarty would have to remain as .php and not
.phpp,
otherwise they wouldn't be able to render the templates.

In the case of Zend Framwork, which I'm most familiar with, the
application, front controller, dispatcher, and action controllers,
and some
services would have to remain as .php so that templates could be
executed.

Oh, and the autoloader can't be .phpp either. But then if it's
.php, then
the autoloader can't be called from .phpp files to include .php
files.

Cheers,
David

It's been awhile since I've used Smarty, but unless my memory is
failing
me, I'm pretty sure it's not restricted to being several points
removed
upstream as you described. I'm not familiar with Zend_View or Twig
so I
can't comment on those.

Thing is, there's no reason why you can't hook any framework into
this.
Worst-case scenario, if the library you're hooking into has a rigid
structure, just write a simple controller class layer to operate on
top of
it, then use that same controller class to interface with the .phpp
stack.
Problem solved. It's really not as complicated or confusing as
you're
making it out to be.

--Kris

Both Smarty and Twig compile your template files down to php
templates.
Zend_View, Aura.View, and Symfony's php view include php files
directly
without a compilation phase.

I don't get how I would write a "simple controller class layer to
operate
on top of it".

Does the inclusion limitation apply to just the script in question,
or the
entire call stack?

A simplified example:
index.php -> FrontController.phpp -> Controller.phpp -> View.phpp
-> can't
include template.phtml

index.php -> FrontController.phpp -> Controller.phpp -> View.php ->
can
include template.phtml ?
But I can't do require_once('View.php') in the controller.

If there's an autoloader involved, it would have to be set up in
index.php, and would also have to be .php so that it can include
both file
types.

index.php -> FrontController.phpp -> Controller.phpp ->
Autoloader.php ->
can include View.php ?

But will that work since there are .phpp files above it in the call
stack?

Cheers,
David

I'm sorry, I was vague on this point in my previous response. The
controller script would be standard .php, not .phpp. And rather than
a
one-dimensional linear progression, there would be parallel stacks,
one
.php and the other .phpp, both coming together in the controller
(which is
.php).

If I get some time this weekend I'll try to throw together a working
example. Perhaps that'll help clarify my thinking on this. =)

--Kris

I missed replying to the list here, sorry!

John LeSueur wrote:

I'm -1 on this, since the main benefit of .phpp is for class/library
files. This handles models just fine, but controllers who include .php
files for templating won't be able to take advantage. Also, any templating
library will have to be written with .php. Smarty, Twig, etc. use class
files just as much as any model or controller, and have just as much reason
to use .phpp.

Kris Craig Wrote:
As I said, this is simply not true. Controllers that include .php
files for templating would still be able to include .phpp files and thus
take full advantage. Again, I would strongly encourage you to review the
diagram posted on the RFC.

But controllers can't be in a .phpp file, even when they are pure php.
Take the following:

Again, I'm not saying that they should be. The controller is a .php
file, not a .phpp file.

But why? it's just code, there's no html? why can't it be .phpp? Sure it
calls some function thats going to spit out html, but the file itself is
pure php, and deserves protection from accidental whitespace just as much
as any file in the model.

You just answered your own question. If the controller calls a function
that spits out HTML, then on a practical level the controller itself is
spitting out raw HTML. That's why.

But again, these are all architectural decisions that are up to the
developer. I don't expect everyone to agree with methods. If you want
your controller to be pure PHP and you can do that without having to
include raw HTML code, then go for it!

//a controller, maybe a class, maybe just a set of functions, but in a
.phpp file
function getLoginPage()
{
//set up some data
//some people like to use plain .php for templates
include 'templates/loginPage.php';
//other people like to use a View library
$view->render('loginPage.tpl');
}

In the case of using a view object, your controller can be a .phpp file.
In the case of the include, it cannot. Now consider the case of the
implementation of the render() method:

function render($template)
{
$compiledTemplate = $this->compile($template);
include $compiledTemplate;
}

Now your render method cannot be in a .phpp file.

Again, the controller should NOT be a .phpp file. Likewise, your model
should NOT be hooking directly to the view.

I'm not sure why you're talking about the model hooking to the view, since
I didn't mention the model at all in my example. I'm only talking about
View and Controller. I think Models will have no problem with your RFC.

Then on this point at least we agree. This is intended for use by the
model. Because the controller interacts directly with the view, I
personally don't think it's a good option for pure PHP, even if the
controller file itself doesn't contain any HTML code. Basically, this
should be determined on a per-stack basis, not a per-file basis IMHO.

Since there seems to be demand for it, we could conceivably create third
type that operates on a per-file basis instead of per-stack (maybe like
.phpm for "PHP Mixed"), though personally I still don't see the point. But
if there's demand for that I wouldn't be opposed to amending the RFC to
include that. What do you think?

The controller hooks to the model. The controller then sanitizes that
and returns it to the view. Alternatively, if you're not conforming to a
pure MVC standard, the controller can also hook to a regular .php file in
the model and pass the data to that. Either way, it all passes through the
controller. The model and view should never be interacting directly. MVC
or not, that's just bad architecture and there are zero advantages to using
such an ad hoc approach.

If a developer insists on using such a broken model, however, they're
more than welcome to! That's what people love (and hate) about PHP. It's
flexible. They just won't be able to use a .phpp file upstream from that,
as it is by its very nature inherently incompatible with such a broken
model. The only way to force it to be compatible would be to make the
.phpp file essentially meaningless.

Much as I think MVC is a great way of doing things, I don't think that
everything else is a broken model, for all applications. The PHP engine and
language really have no business encouraging one way or another. Our big
difference of opinion is that for me, .phpp is a convenience, allowing
files to avoid extraneous whitespace, while for you, .phpp is a way of
encouraging good code structure.

Yeah I went a little overboard in referring to all other models as "broken"
lol.

So if you're writing good code structure, a .phpp file will help you make
it even better. If you're writing bad architecture, then just keep doing
what you're already doing and don't worry about using a .phpp file! This
will in no way stop you from being able to do what you can already do in
PHP. You're just insisting on wanting to use a pure code file for
something that it's not intended to be used for. Just like having object
orientation added in PHP 5 didn't stop you from writing procedural code if
you want to, introducing this in PHP 6 won't stop you from writing
disorganized code if you still want to. What this will do is provide a
valuable option for people who do feel that writing clean, role-segregated
code is important.

What exactly is the benefit of this kind of segregation? why would a
.phpp file care that no other files included after it are .php?

Simple: It's a lot easier to hire a designer and a programmer than it
is to hire two people who are each fluent in both design and programming.
In other words, on complex projects with intense graphical and
functionality requirements, being able to separate the development process
into design and scripting components, without merge conflicts between the
two, is far more efficient and economical. That's why familiarity with the
MVC standard is listed as a requirement on many (if not most) developer job
postings nowadays.

If you have .phpp files, the designer immediately knows to steer clear.
Likewise, it means that the PHP developer can build the model with
impunity because he knows it won't collide with the work that the designer
is doing on the templating layer. The controller is the point where the
two meet, and that would be a .php file which includes both .php and .phpp
files, thus allowing full cooperation and interaction between the two while
simultaneously segregating their roles.

Yes, the segregation provided by MVC is great. I'm not questioning that.
I'm asking about the segregation of include trees of .phpp(code) files from
include trees of .php(template) files. They're already going to be
separated in the filesystem(in any sane application), so designers won't be
looking at .phpp files(and in some cases, may not have access to that
portion of the code tree). I just don't agree that the engine also needs to
create segregated include trees in order to facilitate MVC. There's a lot
of ways to do the V in MVC, and a lot of ways to connect the C to it. It
seems like this RFC puts restrictions on those in an unnecessary way. I'm
not sure we're going to agree on this point(as you said somewhere else,
smart people disagree all the time), but I wanted to make my objections
clear.

When I say they need to be segregated, what I'm referring to is model
code being separated from template code. There is never a valid reason for
the two to interact directly without going through an intermediary (i.e. a
controller). If your code does, ok. Using a .phpp file in that project
probably wouldn't be the best option for you. Either way, your existing
code will continue to work just as it does now. There's no rule saying you
HAVE to convert your code to MVC, after all. This RFC merely provides
support for that, which I believe is warranted given its wide usage and the
significant advantages it would bring to facilitating that.

Again, I'm not talking about Models and Views, or even how Models and
Controllers connect. I'm talking about Views and Controllers. You think
they shouldn't be allowed to be in .phpp, and I think that controllers
definitely should, and that the non-template parts of Views should as well.

Sounds like this might be an argument for a third type to accommodate that
separate purpose. Though personally I don't agree with that architectural
approach, I'd be willing to add that to the RFC as a compromise since
enough of you seem to be asking for that.

Regarding your rendering example, you could make it work by simply
structuring it like so:

frontend.view.php:

<?php

require( "controller.class.php" );
$controller = new Controller();
print $controller->render( "MyTemplate" );

controller.class.php:

<?php

class Controller
{
// Constructor, methods, etc.... Pretend they're all here,
including dispatch, etc.
 public function render( $template )
 {
      // Insert whatever code here.

      // Process some variables used by the template for whatever
reason.
require_once( "model.class.phpp" );
      $model = new Model( $whatever );
      $this->templatevars =
$model->calculate_quantum_particle_density( $somevar, TRUE, 42, "Alan Alda"
);
      // Now get the template and pass the template vars array to it.
      require_once( "templates.view.class.php" );

      $templates = new Templates();
      $html = $templates->load( $template );

      return $model->parse_hypothetical_templatescript( $html,
$this->templatevars );
}
}

I think the point has been made so I'll refrain from conjuring fake model
and template scripts. As you can see, the .phpp and .php code are
interacting perfectly. Of course, it obviously wouldn't make any sense to
have raw HTML code in the template load function since the frontend viewer
is handling that, plus I'd probably have put the variable parsing stuff in
the template class as well but I put it in the model just to illustrate the
point.
If, for some stupid-ass reason, Templates::load() executed over a section
of ?> HTML code, no error would be thrown (it would just look really,
REALLY stupid lol). Why? Because the controller is a .php file, NOT a
.phpp file. As such, it does exactly what a controller should do;
facilitate interaction between the model and view entry points.

And my objection is, the controller has no ?> in it, so it is pure php. It
is just as susceptible to mistakes in whitespace as a file in the model. It
could benefit from .phpp just as much as a file in the model. It also
shouldn't be changed by designers.

Now, if your code has a completely incompatible architecture that has ?>
stuff mixed in all over the place in the stack, then a .phpp file really
isn't appropriate for that project, anyway. But if you do have a clean
separation, then this will enable you to write all the scripts in your
model layer in pure PHP code without having to worry about <?php tags or ?>
HTML crap getting inadvertently mixed-in. If it works for you, use it. If
it doesn't, just keep doing what you're doing.

But my hypothetical code stack is full of pristine code with no ?> mixed
in, except for in the templates. But I can't use .phpp on my pristine
Controller files, because they end up including .php templates.

In reality, I use a view library, so my Controller could use .phpp under
your RFC. But my view library would have to be all .php. And my view
library is a bunch of classes, with no ?> in them. But at some point, it
includes a .php template to do the actual display, so my library can't be
written in .phpp. I think that's wrong, because library code (even a view
library) needs .phpp just as much as any model.

Make sense?

I see exactly what you are saying, and I just think that using .phpp in
only 1/3(Model, but not Controller or View) of the code is restrictive. I
think that any file that doesn't have ?> should be able to take advantage
of .phpp. I see .phpp as a mode for parsing one file. It's not a paradigm
shift, just a shortcut.

John

13 years ago by Matthew Weier O'Phinney — view source

unread

//a controller, maybe a class, maybe just a set of functions, but in a
.phpp file
function getLoginPage()
{
//set up some data
//some people like to use plain .php for templates
include 'templates/loginPage.php';
//other people like to use a View library
$view->render('loginPage.tpl');
}

In the case of using a view object, your controller can be a .phpp file.
In the case of the include, it cannot. Now consider the case of the
implementation of the render() method:

function render($template)
{
$compiledTemplate = $this->compile($template);
include $compiledTemplate;
}

Now your render method cannot be in a .phpp file.

Again, the controller should NOT be a .phpp file. Likewise, your model
should NOT be hooking directly to the view. The controller hooks to the
model. The controller then sanitizes that and returns it to the view.
Alternatively, if you're not conforming to a pure MVC standard,

Sorry, this is where you lose me. There's no "pure" MVC standard,
particularly when it comes to MVC implementation on the web. There are
many, many, many interpretations of how MVC works, and some generally
accepted understanding around separation of concerns, but if you look at
the ecosystem of MVC frameworks in PHP alone, you'll see that none of
the frameworks do things the same way.

On top of this, there's an argument that you're not addressing: most
template engines in PHP either directly consume PHP template files...
or "compile" templates into... PHP template files. As such, sooner or
later, you'll have a class that includes a PHP template file, and that's
where things break for me in this proposal.

I think the "pure PHP" vs "embedded PHP" has to be determined in a
file-by-file basis, if at all -- NOT based on whether or not a file is
consuming a file that has embedded PHP. Once you go down that rabbit
hole, as soon as you have one file with embedded PHP (and most likely,
you will), you'll have to assume the entire project is. At that point,
there's zero benefit at all to making a distinction.

The proposals to use a flag with include, or to provide a separate
"script()" function for switching between pure PHP/embedded PHP make
sense to me. These make it easy for a framework/project to provide
autoloaders that choose the appropriate flag/function necessary to load
the class, and to select the appropriate flag/function when including
embedded artifacts. They also make auditing code easy -- you can grep
for one or the other.

File extensions, on the other hand, are a non-starter, as is any
approach that would insist that any consumer of a script that uses
embedding be marked as embedded as well.

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

13 years ago by Kris Craig — view source

unread

On Fri, Apr 13, 2012 at 7:15 AM, Matthew Weier O'Phinney <
weierophinney@php.net> wrote:

On Thu, Apr 12, 2012 at 8:24 PM, John LeSueur john.lesueur@gmail.com
wrote:

//a controller, maybe a class, maybe just a set of functions, but in a
.phpp file
function getLoginPage()
{
//set up some data
//some people like to use plain .php for templates
include 'templates/loginPage.php';
//other people like to use a View library
$view->render('loginPage.tpl');
}

In the case of using a view object, your controller can be a .phpp
file.
In the case of the include, it cannot. Now consider the case of the
implementation of the render() method:

function render($template)
{
$compiledTemplate = $this->compile($template);
include $compiledTemplate;
}

Now your render method cannot be in a .phpp file.

Again, the controller should NOT be a .phpp file. Likewise, your model
should NOT be hooking directly to the view. The controller hooks to the
model. The controller then sanitizes that and returns it to the view.
Alternatively, if you're not conforming to a pure MVC standard,

Sorry, this is where you lose me. There's no "pure" MVC standard,
particularly when it comes to MVC implementation on the web. There are
many, many, many interpretations of how MVC works, and some generally
accepted understanding around separation of concerns, but if you look at
the ecosystem of MVC frameworks in PHP alone, you'll see that none of
the frameworks do things the same way.

Yeah I went a bit overboard on the whole "MVC purity" soapbox. I do
believe that this way is the correct approach, but deriding all other
architectures as "broken" was a bit much.

On top of this, there's an argument that you're not addressing: most
template engines in PHP either directly consume PHP template files...
or "compile" templates into... PHP template files. As such, sooner or
later, you'll have a class that includes a PHP template file, and that's
where things break for me in this proposal.

They don't break because nobody in their right mind would ever try to
include a .phpp file in a framework like that. If its stack is so
entangled, the very notion of a pure PHP stack is just incompatible. So
your best bet on a framework like that would be to stick with .php.

I think the "pure PHP" vs "embedded PHP" has to be determined in a
file-by-file basis, if at all -- NOT based on whether or not a file is
consuming a file that has embedded PHP. Once you go down that rabbit
hole, as soon as you have one file with embedded PHP (and most likely,
you will), you'll have to assume the entire project is. At that point,
there's zero benefit at all to making a distinction.

I believe the exact opposite to be true. If you expect a file you're
including to output only pure PHP code, but then it outputs a bunch of
HTML code, it shouldn't matter whether that code came from the file itself
or an included file. The result is the same either way. If that doesn't
treat them both the same, that lack of consistency basically makes the
whole point of including a pure PHP stack useless.

Alternatively, I suppose we could create a third type; one that goes on a
per-file basis instead of per-stack. While I personally don't see any
value to this, a few of you are expressing a desire for that, so I'd be
willing to meet you halfway on this and add that to the RFC.

The proposals to use a flag with include, or to provide a separate
"script()" function for switching between pure PHP/embedded PHP make
sense to me. These make it easy for a framework/project to provide
autoloaders that choose the appropriate flag/function necessary to load
the class, and to select the appropriate flag/function when including
embedded artifacts. They also make auditing code easy -- you can grep
for one or the other.

The problem with that is you're basically creating two separate methods for
parsing the same file. Inherently, one of those methods will always work,
and the other method will always break. That makes no sense to me. If a
PHP script doesn't contain a <?php tag but it's all PHP code anyway, the
only keyword under your model that would ever work is script().
Conversely, if it does have a <?php tag and/or ?> content, the only keyword
that would work is include()/require(). So that completely defeats the
whole purpose of having separate keywords, since by definition the
distinction is still handling at the file-level anyway. So rather than
creating meaningless keyword distinctions, differentiating the file
extension is the logical approach.

File extensions, on the other hand, are a non-starter, as is any
approach that would insist that any consumer of a script that uses
embedding be marked as embedded as well.

See above. Using separate keywords doesn't change this; it just makes it
more confusing and tedious.

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

13 years ago by John Crenshaw — view source

unread

On top of this, there's an argument that you're not addressing: most
template engines in PHP either directly consume PHP template files...
or "compile" templates into... PHP template files. As such, sooner or
later, you'll have a class that includes a PHP template file, and
that's where things break for me in this proposal.

They don't break because nobody in their right mind would ever try to
include a .phpp file in a framework like that. If its stack is so entangled,
the very notion of a pure PHP stack is just incompatible. So your best bet
on a framework like that would be to stick with .php.

Um, so if you aren't using any form of template engine whatsoever, what are you proposing? You're saying we should all go back to the good ol' C days of trying to put together valid markup using string concatenation? (Or worse, manipulation of DOM classes?) No thanks. IMO this is a bit like blowing up London to stop a jaywalker.

After a lot of thought I've decided that I'm strongly opposed to the nature of this proposal at a fundamental level. It isn't that I just wouldn't use it. This proposal is inherently destructive to the PHP development community. This effectively attempts to split PHP into two languages. Current PHP isn't really compatible with the proposed ".phpp" version of PHP, in the sense that you can't safely use both in the same code base. Unfortunately this will not be clear to anybody at first, which will lead to mass proliferation of .phpp libraries which are like poison to any unsuspecting PHP user foolish enough to try to use one. This isn't just a BC thing, it is really a permanent language fork.

John Crenshaw
Priacta, Inc.

--
I am using the free version of SPAMfighter.
We are a community of 7 million users fighting spam.
SPAMfighter has removed 839 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len

The Professional version does not have this message

13 years ago by Kris Craig — view source

unread

On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw johncrenshaw@priacta.comwrote:

On top of this, there's an argument that you're not addressing: most
template engines in PHP either directly consume PHP template files...
or "compile" templates into... PHP template files. As such, sooner or
later, you'll have a class that includes a PHP template file, and
that's where things break for me in this proposal.

They don't break because nobody in their right mind would ever try to
include a .phpp file in a framework like that. If its stack is so
entangled,
the very notion of a pure PHP stack is just incompatible. So your best
bet
on a framework like that would be to stick with .php.

Um, so if you aren't using any form of template engine whatsoever, what
are you proposing? You're saying we should all go back to the good ol' C
days of trying to put together valid markup using string concatenation? (Or
worse, manipulation of DOM classes?) No thanks. IMO this is a bit like
blowing up London to stop a jaywalker.

That's a logical fallacy; i.e. your contention relies on the premise that,
if this doesn't work with every single framework known to exist, then it
doesn't work with any template engine whatsoever. That's just patently
ridiculous and could not be further from the truth.

After a lot of thought I've decided that I'm strongly opposed to the
nature of this proposal at a fundamental level. It isn't that I just
wouldn't use it. This proposal is inherently destructive to the PHP
development community. This effectively attempts to split PHP into two
languages. Current PHP isn't really compatible with the proposed ".phpp"
version of PHP, in the sense that you can't safely use both in the same
code base. Unfortunately this will not be clear to anybody at first, which
will lead to mass proliferation of .phpp libraries which are like poison to
any unsuspecting PHP user foolish enough to try to use one. This isn't just
a BC thing, it is really a permanent language fork.

A few points:

How exactly will this single-handedly "destroy the PHP community"? I
will give you bonus points for creative hyperbole, though.
This does NOT split PHP into two languages. In fact, there are no
changes to the language in this RFC. The only difference is a new file
type that parses PHP without the need for a <?php tag and with ?> raw HTML
code not being permitted within that file type's stack. Again, bonus
points for wild hyperbole....
Current PHP is perfectly compatible with this, as would be many if
not most implementations (some might require more work than others). And
those that aren't aren't being forced to use this new file type in their
projects anyway. I think what's at issue is the particular framework that
you are accustomed to working with would not mesh well with this. But
that's a very narrow subset of PHP. The language itself and probably most
implementations of it would have no problem incorporating this if they
chose to do so. The "all or nothing" mindset you're expressing is not
logical.
For the gazillionth time, there is no BC break in this RFC! The
language is not being redefined as you're characterizing it and .php files
will continue to behave exactly as they do now.
Using cheap fear tactics like "any unsuspecting PHP user foolish
enough" and "poison" only serves to cheapen this discussion and erode your
own credibility.

--Kris

John Crenshaw
Priacta, Inc.

--
I am using the free version of SPAMfighter.
We are a community of 7 million users fighting spam.
SPAMfighter has removed 839 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len

The Professional version does not have this message

13 years ago by Matthew Weier O'Phinney — view source

unread

--f46d04447f47ae95ec04bd949e5f
Content-Type: text/plain; charset=ISO-8859-1

On top of this, there's an argument that you're not addressing: most
template engines in PHP either directly consume PHP template files...
or "compile" templates into... PHP template files. As such, sooner or
later, you'll have a class that includes a PHP template file, and
that's where things break for me in this proposal.

They don't break because nobody in their right mind would ever try to
include a .phpp file in a framework like that. If its stack is so
entangled,
the very notion of a pure PHP stack is just incompatible. So your best
bet
on a framework like that would be to stick with .php.

Um, so if you aren't using any form of template engine whatsoever, what
are you proposing? You're saying we should all go back to the good ol' C
days of trying to put together valid markup using string concatenation? (Or
worse, manipulation of DOM classes?) No thanks. IMO this is a bit like
blowing up London to stop a jaywalker.

That's a logical fallacy; i.e. your contention relies on the premise that,
if this doesn't work with every single framework known to exist, then it
doesn't work with any template engine whatsoever. That's just patently
ridiculous and could not be further from the truth.

Then point to ONE widely used, OSS templating engine or MVC framework
that will be able to operate as pure PHP. (My mustache library does not
count.)

I'll give you time to look for one.

Hint: I don't think you'll find any.

Most PHP template engines compile templates to HTML with embedded PHP.
This does NOT mean that including such a PHP file immediately spits out
output -- on the contrary: every PHP templating engine I've seen by
default will use output buffering to allow capturing the output to a
variable, which you later spit out.

This is one reason I'm very uncertain about your assertion that
including an embedded PHP file taints the class including it, as well as
any up the stack. The code itself is never really operating in "mixed"
or "embed" mode -- only the template file itself is. If you insist on
the tainting aspect, I honestly do not see this proposal gaining ground;
few if any exising frameworks or template engines will gain anything by
it, much less be able to take advantage of it, and the work necessary to
make it possible makes it undesirable, except as an achievement ("look!
I did it!").

Finally, you're constantly dismissing the arguments that specifying a
specific suffix is a bad idea -- but without making a reasonable
argument as to why suffixes are okay. I personally write a lot of CLI
scripts in PHP -- and typically do not give them extensions. Under your
proposal, even those these do not operate in embed mode, because they do
not have the "blessed" extension, they cannot omit the <?php tag. This
is limiting, and goes against the idea of portability.

I'm not going to go as far as John and claim it's an attack on existing
users or anything -- but I will argue that you're ignoring very, very
common use cases and patterns used in PHP, and over-estimating how
likely people will want to use the feature as proposed knowing the
limitations.

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

13 years ago by Kris Craig — view source

unread

On Fri, Apr 13, 2012 at 1:02 PM, Matthew Weier O'Phinney <
weierophinney@php.net> wrote:

--f46d04447f47ae95ec04bd949e5f
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw <
johncrenshaw@priacta.com> wrote:

On top of this, there's an argument that you're not addressing:
most
template engines in PHP either directly consume PHP template
files...
or "compile" templates into... PHP template files. As such, sooner
or
later, you'll have a class that includes a PHP template file, and
that's where things break for me in this proposal.

They don't break because nobody in their right mind would ever try to
include a .phpp file in a framework like that. If its stack is so
entangled,
the very notion of a pure PHP stack is just incompatible. So your
best
bet
on a framework like that would be to stick with .php.

Um, so if you aren't using any form of template engine whatsoever, what
are you proposing? You're saying we should all go back to the good ol'
C
days of trying to put together valid markup using string
concatenation? (Or
worse, manipulation of DOM classes?) No thanks. IMO this is a bit like
blowing up London to stop a jaywalker.

That's a logical fallacy; i.e. your contention relies on the premise
that,
if this doesn't work with every single framework known to exist, then it
doesn't work with any template engine whatsoever. That's just patently
ridiculous and could not be further from the truth.

Then point to ONE widely used, OSS templating engine or MVC framework
that will be able to operate as pure PHP. (My mustache library does not
count.)

I'll give you time to look for one.

Hint: I don't think you'll find any.

Why would I want to prove a point that I was never trying to make in the
first place?

I've never contended that there are frameworks that are 100% pure PHP
code. That's not a requirement for .phpp anyway. So I'm not sure why
you're introducing that idea all of a sudden.

Most PHP template engines compile templates to HTML with embedded PHP.
This does NOT mean that including such a PHP file immediately spits out
output -- on the contrary: every PHP templating engine I've seen by
default will use output buffering to allow capturing the output to a
variable, which you later spit out.

See above.

This is one reason I'm very uncertain about your assertion that
including an embedded PHP file taints the class including it, as well as
any up the stack. The code itself is never really operating in "mixed"
or "embed" mode -- only the template file itself is. If you insist on
the tainting aspect, I honestly do not see this proposal gaining ground;
few if any exising frameworks or template engines will gain anything by
it, much less be able to take advantage of it, and the work necessary to
make it possible makes it undesirable, except as an achievement ("look!
I did it!").

Finally, you're constantly dismissing the arguments that specifying a
specific suffix is a bad idea -- but without making a reasonable
argument as to why suffixes are okay.

That's false. Please refer to my previous messages from today. I
explained in detail why a filename extension is preferable to new
keywords. Rather than forcing me to repeat myself, please read what I've
already posted on the matter.

I personally write a lot of CLI
scripts in PHP -- and typically do not give them extensions. Under your
proposal, even those these do not operate in embed mode, because they do
not have the "blessed" extension, they cannot omit the <?php tag. This
is limiting, and goes against the idea of portability.

I'm not going to go as far as John and claim it's an attack on existing
users or anything -- but I will argue that you're ignoring very, very
common use cases and patterns used in PHP, and over-estimating how
likely people will want to use the feature as proposed knowing the
limitations.

I think you're the one who is ignoring what's being said. I offered a
compromise solution that addresses your concerns and neither of you have
even acknowledged it, let alone responded to it. If you're not willing to
actually read my posts and look for common ground, then there's no reason
for me to say anything further.

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

13 years ago by John Crenshaw — view source

unread

Sent: Friday, April 13, 2012 3:39 PM

On top of this, there's an argument that you're not addressing: most
template engines in PHP either directly consume PHP template files...
or "compile" templates into... PHP template files. As such, sooner or
later, you'll have a class that includes a PHP template file, and
that's where things break for me in this proposal.

They don't break because nobody in their right mind would ever try to
include a .phpp file in a framework like that. If its stack is so entangled,
the very notion of a pure PHP stack is just incompatible. So your best bet
on a framework like that would be to stick with .php.
Um, so if you aren't using any form of template engine whatsoever, what are you
proposing? You're saying we should all go back to the good ol' C days of trying
to put together valid markup using string concatenation? (Or worse, manipulation
of DOM classes?) No thanks. IMO this is a bit like blowing up London to stop a
jaywalker.

That's a logical fallacy; i.e. your contention relies on the premise that, if this
doesn't work with every single framework known to exist, then it doesn't work with
any template engine whatsoever. That's just patently ridiculous and could not be
further from the truth.

I think you missed the problem entirely. All but a tiny handful of template engines (and ALL of the template engines that are fast and powerful enough to use as the view component for a site) compile into PHP templates. Once something is included in the way you propose there is no longer ANY viable view option. The only way to output anything at that point is with strings and echos. The entire reason PHP became popular in the first place is because it was a first class template language. Web development is, at the end of the day, metaprogramming.

After a lot of thought I've decided that I'm strongly opposed to the nature of
this proposal at a fundamental level. It isn't that I just wouldn't use it. This
proposal is inherently destructive to the PHP development community. This
effectively attempts to split PHP into two languages. Current PHP isn't really
compatible with the proposed ".phpp" version of PHP, in the sense that you can't
safely use both in the same code base. Unfortunately this will not be clear to
anybody at first, which will lead to mass proliferation of .phpp libraries which
are like poison to any unsuspecting PHP user foolish enough to try to use one.
This isn't just a BC thing, it is really a permanent language fork.

A few points:

How exactly will this single-handedly "destroy the PHP community"? I will give
you bonus points for creative hyperbole, though.

That's not what I said. I said it is "inherently destructive to the PHP development community." I stand by that. It segregates the community and effectively divides PHP into two languages that both seem (on the surface) to be the same thing. Problem is they're not really compatible. If they are used together one will eventually cause the other to break in confusing ways.

In this thread we've had people suggest that library developers should use this .phpp stuff. That's EXACTLY the problem I'm worried about. All it takes is one callback, one event, one autoloader, one error handler, one anything, and the entire application system falls apart because one library decided that it didn't need template mode.

If the division were clear it wouldn't even be so bad, but it's not clear. Everything is called PHP, and this is getting marketed as just "use the .phpp extension if your file doesn't use templating". It is devilishly subtle, and the average library developer who decides to do this won't realize at all the hell that they are about to release on the web developers who use their library, because if their library is in the call stack at all, for any reason, any attempt at templating will die.

This does NOT split PHP into two languages. In fact, there are no changes to
the language in this RFC. The only difference is a new file type that parses PHP
without the need for a <?php tag and with ?> raw HTML code not being permitted
within that file type's stack. Again, bonus points for wild hyperbole....

Yeah, you missed it, which ironically is exactly my concern. I refer you to two paragraphs earlier.

You've said before that no sane developer would include .phpp files somewhere that doesn't have a rigidly defined inclusion and operation structure. This is exactly the problem. Most MVC frameworks now heavily use autoloaders and other patterns (plugins, listeners, error handlers, etc.) that do NOT have a rigid inclusion structure. And that's all OK (wonderful in fact, it allows for incredible things). This syntax change though forces a division in the community with these MVC frameworks on one side, and any library that figured it didn't need templating on the other side. The two sides will be at constant war, because their code will never be safe to use together.

Current PHP is perfectly compatible with this, as would be many if not most
implementations (some might require more work than others). And those that aren't
aren't being forced to use this new file type in their projects anyway. I think
what's at issue is the particular framework that you are accustomed to working with
would not mesh well with this. But that's a very narrow subset of PHP. The
language itself and probably most implementations of it would have no problem
incorporating this if they chose to do so. The "all or nothing" mindset you're
expressing is not logical.

Um, wow. That's just condescending. I'm tempted to not even respond do that. I've used too many frameworks to count and ranging all the way from the looseness of "on the metal" code down to the rigid structure of Magento and Zend. There isn't a single framework I've worked with (not one) that could start using .phpp short of a massive architecture overhaul. The old ones use a terrible nasty templating structure, the new ones make heavy use of autoloaders and MVC.

For the gazillionth time, there is no BC break in this RFC! The language is not
being redefined as you're characterizing it and .php files will continue to behave
exactly as they do now.

Yes, you are right. There is no BC break. It's worse than that. You are introducing an entirely new class of code that is not only incompatible with older code, it is even incompatible with code written for the same version of PHP, because once you start into .phpp you can't get back out.

Using cheap fear tactics like "any unsuspecting PHP user foolish enough" and "poison"
only serves to cheapen this discussion and erode your own credibility.

--Kris

Look, these aren't "cheap fear tactics". Yes, it's scary (I know I'm terrified), but I've articulated the reasons why bad stuff happens, and other developers have raised many of the same concerns.

Finally, your main argument for this is that the current way allows bad architecture. Let me address that specifically:

It is not PHP's mandate to make sure everyone uses good architecture for their code.
Enforcing architecture rules is really more a job for PHP CodeSniffer. If CodeSniffer can't enforce it, then your developers won't be able to keep track of whether their new code breaks the rule either (which would mean you probably have a bad rule).
Not everyone agrees with your assessment of the badness of this architecture. In fact, the structure of most current MVC frameworks would suggest that most developers have a decidedly different perspective on this (which is that view rendering should be encapsulated, but it doesn't really matter where in the call stack the encapsulation actually occurred).
There's an architectural elephant in the room. To make this work every file must know something substantial about the internal operation of every file it includes, and every file that those files include, and all the files that might get included with it in the stack, and much choose the appropriate file extension to match. This is an egregious violation of encapsulation.
The structure advocated by your RFC is an anti-pattern. To make it work you have to throw out MVC, listeners, plugins, callbacks, and/or templates, and/or have to introduce monolithic lists of includes, string escaping + echo, and library compatibility problems. This is what I was talking about when I said you were bombing London to stop a jaywalker. Maybe there's a debatable code structure issue that some people don't like with including templates from code files, fine. But, if fixing it causes this sort of collateral damage then really, just leave it.

John Crenshaw
Priacta, Inc.

The Professional version does not have this message

13 years ago by Lester Caine — view source

unread

John Crenshaw wrote:

I think that covered just about everything quite tidily John. Certainly a lot
more succinct than I would have managed!
Well put ...

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

13 years ago by Kris Craig — view source

unread

On Sat, Apr 14, 2012 at 11:29 AM, John Crenshaw johncrenshaw@priacta.comwrote:

Sent: Friday, April 13, 2012 3:39 PM

On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw <
johncrenshaw@priacta.com> wrote:

On top of this, there's an argument that you're not addressing:
most
template engines in PHP either directly consume PHP template
files...
or "compile" templates into... PHP template files. As such, sooner
or
later, you'll have a class that includes a PHP template file, and
that's where things break for me in this proposal.

They don't break because nobody in their right mind would ever try to
include a .phpp file in a framework like that. If its stack is so
entangled,
the very notion of a pure PHP stack is just incompatible. So your
best bet
on a framework like that would be to stick with .php.
Um, so if you aren't using any form of template engine whatsoever,
what are you
proposing? You're saying we should all go back to the good ol' C days
of trying
to put together valid markup using string concatenation? (Or worse,
manipulation
of DOM classes?) No thanks. IMO this is a bit like blowing up London
to stop a
jaywalker.

That's a logical fallacy; i.e. your contention relies on the premise
that, if this
doesn't work with every single framework known to exist, then it doesn't
work with
any template engine whatsoever. That's just patently ridiculous and
could not be
further from the truth.

I think you missed the problem entirely. All but a tiny handful of
template engines (and ALL of the template engines that are fast and
powerful enough to use as the view component for a site) compile into PHP
templates. Once something is included in the way you propose there is no
longer ANY viable view option. The only way to output anything at that
point is with strings and echos. The entire reason PHP became popular in
the first place is because it was a first class template language. Web
development is, at the end of the day, metaprogramming.

As I said, this is NOT an inherent conflict. What it comes down to is
how this
"compilation", as you put it, is taking place.

After a lot of thought I've decided that I'm strongly opposed to the
nature of
this proposal at a fundamental level. It isn't that I just wouldn't
use it. This
proposal is inherently destructive to the PHP development community.
This
effectively attempts to split PHP into two languages. Current PHP
isn't really
compatible with the proposed ".phpp" version of PHP, in the sense that
you can't
safely use both in the same code base. Unfortunately this will not be
clear to
anybody at first, which will lead to mass proliferation of .phpp
libraries which
are like poison to any unsuspecting PHP user foolish enough to try to
use one.
This isn't just a BC thing, it is really a permanent language fork.

A few points:

How exactly will this single-handedly "destroy the PHP community"? I
will give
you bonus points for creative hyperbole, though.

That's not what I said. I said it is "inherently destructive to the PHP
development community." I stand by that. It segregates the community and
effectively divides PHP into two languages that both seem (on the surface)
to be the same thing. Problem is they're not really compatible. If they are
used together one will eventually cause the other to break in confusing
ways.

No, it doesn't. I've already explained how your claim that it creates "2
languages" is inaccurate. Simply repeating a false claim won't make it any
more true. That, too, is a logical fallacy.

Also, if you claim that something is "inherently destructive to the PHP
development community," you're essentially saying that it will
single-handedly destroy the PHP community, which is an utterly ridiculous
statement no matter how you look at it. That's what I mean when I refer to
cheap scare tactics.

In this thread we've had people suggest that library developers should use
this .phpp stuff. That's EXACTLY the problem I'm worried about. All it
takes is one callback, one event, one autoloader, one error handler, one
anything, and the entire application system falls apart because one library
decided that it didn't need template mode.

And? That same argument could be made to argue that the header() function
should be eliminated. As we've seen in the separate threads about LFI, the
developer has to take some responsibility for not writing bad code. The
problem you mention is *easily *avoidable. If you're mixing your
autoloaders/handlers/etc in such an ad hoc fashion, then using that with
.phpp would not be a good idea.

Also, I've repeatedly offered a third solution that would alleviate
concerns raised about these specific cases, but you two have yet to even
acknowledge it, let alone respond to it. That suggests, to me at least,
that you're more concerned with just shooting this down on any grounds you
can find rather than actually work towards a solution that works.

If the division were clear it wouldn't even be so bad, but it's not clear.
Everything is called PHP, and this is getting marketed as just "use the
.phpp extension if your file doesn't use templating". It is devilishly
subtle, and the average library developer who decides to do this won't
realize at all the hell that they are about to release on the web
developers who use their library, because if their library is in the call
stack at all, for any reason, any attempt at templating will die.

Again, that's simply not accurate. Do some research on this, as there are
many, MANY established, well-known methods for dealing with these issues
already out there. The MVC approach that I outlined is just one of them.
PHP is far less rigid than you seem to be giving it credit for.

This does NOT split PHP into two languages. In fact, there are no
changes to
the language in this RFC. The only difference is a new file type that
parses PHP
without the need for a <?php tag and with ?> raw HTML code not being
permitted
within that file type's stack. Again, bonus points for wild
hyperbole....

Yeah, you missed it, which ironically is exactly my concern. I refer you
to two paragraphs earlier.

You seem to be the one who has "missed it." I would refer you to my
previous paragraphs on the subject. This doesn't create a separate
language, nor does it do anything even *resembling *that. It's just a
slight variation to the parsing behavior, nothing more. The language
itself is completely untouched by this.

You've said before that no sane developer would include .phpp files
somewhere that doesn't have a rigidly defined inclusion and operation
structure. This is exactly the problem. Most MVC frameworks now heavily use
autoloaders and other patterns (plugins, listeners, error handlers, etc.)
that do NOT have a rigid inclusion structure. And that's all OK (wonderful
in fact, it allows for incredible things). This syntax change though forces
a division in the community with these MVC frameworks on one side, and any
library that figured it didn't need templating on the other side. The two
sides will be at constant war, because their code will never be safe to use
together.

Please refer to this article: http://en.wikipedia.org/wiki/Weasel_word

Current PHP is perfectly compatible with this, as would be many if
not most
implementations (some might require more work than others). And those
that aren't
aren't being forced to use this new file type in their projects anyway.
I think
what's at issue is the particular framework that you are accustomed to
working with
would not mesh well with this. But that's a very narrow subset of PHP.
The
language itself and probably most implementations of it would have no
problem
incorporating this if they chose to do so. The "all or nothing" mindset
you're
expressing is not logical.

Um, wow. That's just condescending. I'm tempted to not even respond do
that. I've used too many frameworks to count and ranging all the way from
the looseness of "on the metal" code down to the rigid structure of Magento
and Zend. There isn't a single framework I've worked with (not one) that
could start using .phpp short of a massive architecture overhaul. The old
ones use a terrible nasty templating structure, the new ones make heavy use
of autoloaders and MVC.

If you see that as somehow condescending, then I would respectfully suggest
that you grow a thicker skin.

What you're complaining about is a very narrow problem, but you're
portraying it as if it encompasses "most" (see "weasel words," above) PHP
frameworks/libraries/etc, which you appear to be basing solely off of your
own anecdotal experience. Pointing out this inherent flaw in your
reasoning is neither "condescending" nor unreasonable.

And again, you keep using wildly hyperbolic terms like, "massive
architectural overhaul," and, "forces a division in the community."
Neither characterization is applicable to this proposal. The fact is,
some frameworks can be made to work with this, others can't. If yours
can't, then don't stress about it. There's no rule saying you have to use
this file type if what you're doing is not compatible with its purpose.

Oh and at the risk of repeating myself, I still have yet to hear any
response from either of you regarding the compromise approach I offered.
If you're actually genuinely concerned about making this compatible with
more frameworks and not just trolling, you should stop ignoring my attempts
to reach at least some common ground on this.

--Kris

For the gazillionth time, there is no BC break in this RFC! The
language is not
being redefined as you're characterizing it and .php files will continue
to behave
exactly as they do now.

Yes, you are right. There is no BC break. It's worse than that. You are
introducing an entirely new class of code that is not only incompatible
with older code, it is even incompatible with code written for the same
version of PHP, because once you start into .phpp you can't get back out.

Using cheap fear tactics like "any unsuspecting PHP user foolish
enough" and "poison"
only serves to cheapen this discussion and erode your own credibility.

--Kris

Look, these aren't "cheap fear tactics". Yes, it's scary (I know I'm
terrified), but I've articulated the reasons why bad stuff happens, and
other developers have raised many of the same concerns.

Finally, your main argument for this is that the current way allows bad
architecture. Let me address that specifically:

It is not PHP's mandate to make sure everyone uses good architecture
for their code.

Enforcing architecture rules is really more a job for PHP CodeSniffer.
If CodeSniffer can't enforce it, then your developers won't be able to keep
track of whether their new code breaks the rule either (which would mean
you probably have a bad rule).

Not everyone agrees with your assessment of the badness of this
architecture. In fact, the structure of most current MVC frameworks would
suggest that most developers have a decidedly different perspective on this
(which is that view rendering should be encapsulated, but it doesn't really
matter where in the call stack the encapsulation actually occurred).

There's an architectural elephant in the room. To make this work every
file must know something substantial about the internal operation of every
file it includes, and every file that those files include, and all the
files that might get included with it in the stack, and much choose the
appropriate file extension to match. This is an egregious violation of
encapsulation.

The structure advocated by your RFC is an anti-pattern. To make it work
you have to throw out MVC, listeners, plugins, callbacks, and/or templates,
and/or have to introduce monolithic lists of includes, string escaping +
echo, and library compatibility problems. This is what I was talking about
when I said you were bombing London to stop a jaywalker. Maybe there's a
debatable code structure issue that some people don't like with including
templates from code files, fine. But, if fixing it causes this sort of
collateral damage then really, just leave it.

John Crenshaw
Priacta, Inc.

--
I am using the free version of SPAMfighter.
We are a community of 7 million users fighting spam.
SPAMfighter has removed 839 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len

The Professional version does not have this message

13 years ago by Arvids Godjuks — view source

unread

16 апреля 2012 г. 16:09 пользователь Tom Boutell tom@punkave.com написал:

These tools already strip <?php tags, they would need minimal changes to
support rolling in a .phpp file unmodified. Unless I am missing something?

Sent from my iPhone

On Apr 15, 2012, at 5:30 PM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

I posted the bellow text in other thread, but i should have it post here,
so i'm reposting it to this thread.

Well, it's time for me to remind about the techique many use (and some
frameworks provide it out of the box) - the application file
concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes mostly
used core classes in one big file.that loads much faster and is used for
production. Any other framework has user extentions or other type of
solutions for this to speed up the application, and it makes really big
difference.
So there is a good question - how the hell in a MVC framework would i
combine my models, controllers, components and other stuff that will
definetly be as in .php so in .pphp. And not every file will be cached
like
that - some will remain as distinct files even in production.

The further discussion goes the more questions there is and less answers
there are.

Yes they obviously do, but that's not what I'm concerned about.
What I'm concerned is that code from .php and .pphp files get's mixed in
together - template engine related stuff is used as much, as do
controllers, session handling classes and bunch of other stuff that by
definition is .pphp stuff, but the template stuff is .php and it includes
templates. So basically everything just has to fall back to the embedded
PHP mode to work and we have no gain from the proposal what so ever - it
just becomes useless.

That's not counting other issues that people and I have been voicing and to
be honest, I never saw a reply to any of it. Maybe there is a reply to
all those questions, but they are under wall of text that usually goes in
reply - that just discourages to read it at all.

13 years ago by Tom Boutell — view source

unread

Oh I see. Yes, this is one of the reasons I don't like the "pure can't
include non-pure" idea.

Another reason: you can't write generic algorithms. PHP 5.4 has much
improved support for anonymous functions, so we should see an increase
in libraries that take a few functions as parameters and carry out an
operation via those functions. But what if one of those functions
requires something from a .php file? Whoops, I guess it's not a
generic sorting algorithm library I just released, it's a "generic
sorting as long as none of your functions touch a .php file" algorithm
library. And good luck figuring this out when it happens.

Kris has pointed out that you could still load a .php file via a
function that was defined earlier in a .php file that later includes
.phpp. But this just means that, like my RFC, his RFC contains a
compromise about strictness. It's just that his compromise is more
confusing and less likely to be understood before the user gets
frustrated and declares the whole thing not worth messing with. I
think ".phpp files don't contain <?php and ?> but can require and
include files that do" is a much clearer compromise, one that will get
us what we want (an ever increasing percentage of .phpp files) without
making enemies and generating opposition along the way to that better
place.

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

16 апреля 2012 г. 16:09 пользователь Tom Boutell tom@punkave.com написал:

These tools already strip <?php tags, they would need minimal changes to
support rolling in a .phpp file unmodified. Unless I am missing something?

Sent from my iPhone

On Apr 15, 2012, at 5:30 PM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

I posted the bellow text in other thread, but i should have it post
here,
so i'm reposting it to this thread.

Well, it's time for me to remind about the techique many use (and some
frameworks provide it out of the box) - the application file
concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes mostly
used core classes in one big file.that loads much faster and is used for
production. Any other framework has user extentions or other type of
solutions for this to speed up the application, and it makes really big
difference.
So there is a good question - how the hell in a MVC framework would i
combine my models, controllers, components and other stuff that will
definetly be as in .php so in .pphp. And not every file will be cached
like
that - some will remain as distinct files even in production.

The further discussion goes the more questions there is and less answers
there are.

Yes they obviously do, but that's not what I'm concerned about.
What I'm concerned is that code from .php and .pphp files get's mixed in
together - template engine related stuff is used as much, as do controllers,
session handling classes and bunch of other stuff that by definition is
.pphp stuff, but the template stuff is .php and it includes templates. So
basically everything just has to fall back to the embedded PHP mode to work
and we have no gain from the proposal what so ever - it just becomes
useless.

That's not counting other issues that people and I have been voicing and to
be honest, I never saw a reply to any of it. Maybe there is a reply to
all those questions, but they are under wall of text that usually goes in
reply - that just discourages to read it at all.

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

13 years ago by Tom Boutell — view source

unread

Also, Kris's proposal requires that an additional flag be tracked all
the way down through the stack of requires and includes from the point
where pure mode is first encountered, remembering that we're in pure
mode. Note that this flag cannot be a global variable because .php
files that were loaded before this .phpp file are still permitted to
load things, including when acting as autoloaders on behalf of .phpp
code... my head hurts. This cannot be the cleanest way to solve the
problem.

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

Oh I see. Yes, this is one of the reasons I don't like the "pure can't
include non-pure" idea.

Another reason: you can't write generic algorithms. PHP 5.4 has much
improved support for anonymous functions, so we should see an increase
in libraries that take a few functions as parameters and carry out an
operation via those functions. But what if one of those functions
requires something from a .php file? Whoops, I guess it's not a
generic sorting algorithm library I just released, it's a "generic
sorting as long as none of your functions touch a .php file" algorithm
library. And good luck figuring this out when it happens.

Kris has pointed out that you could still load a .php file via a
function that was defined earlier in a .php file that later includes
.phpp. But this just means that, like my RFC, his RFC contains a
compromise about strictness. It's just that his compromise is more
confusing and less likely to be understood before the user gets
frustrated and declares the whole thing not worth messing with. I
think ".phpp files don't contain <?php and ?> but can require and
include files that do" is a much clearer compromise, one that will get
us what we want (an ever increasing percentage of .phpp files) without
making enemies and generating opposition along the way to that better
place.

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

16 апреля 2012 г. 16:09 пользователь Tom Boutell tom@punkave.com написал:

These tools already strip <?php tags, they would need minimal changes to
support rolling in a .phpp file unmodified. Unless I am missing something?

Sent from my iPhone

On Apr 15, 2012, at 5:30 PM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

I posted the bellow text in other thread, but i should have it post
here,
so i'm reposting it to this thread.

Well, it's time for me to remind about the techique many use (and some
frameworks provide it out of the box) - the application file
concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes mostly
used core classes in one big file.that loads much faster and is used for
production. Any other framework has user extentions or other type of
solutions for this to speed up the application, and it makes really big
difference.
So there is a good question - how the hell in a MVC framework would i
combine my models, controllers, components and other stuff that will
definetly be as in .php so in .pphp. And not every file will be cached
like
that - some will remain as distinct files even in production.

The further discussion goes the more questions there is and less answers
there are.

Yes they obviously do, but that's not what I'm concerned about.
What I'm concerned is that code from .php and .pphp files get's mixed in
together - template engine related stuff is used as much, as do controllers,
session handling classes and bunch of other stuff that by definition is
.pphp stuff, but the template stuff is .php and it includes templates. So
basically everything just has to fall back to the embedded PHP mode to work
and we have no gain from the proposal what so ever - it just becomes
useless.

That's not counting other issues that people and I have been voicing and to
be honest, I never saw a reply to any of it. Maybe there is a reply to
all those questions, but they are under wall of text that usually goes in
reply - that just discourages to read it at all.

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

unread

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

Also, Kris's proposal requires that an additional flag be tracked all
the way down through the stack of requires and includes from the point
where pure mode is first encountered, remembering that we're in pure
mode. Note that this flag cannot be a global variable because .php
files that were loaded before this .phpp file are still permitted to
load things, including when acting as autoloaders on behalf of .phpp
code... my head hurts. This cannot be the cleanest way to solve the
problem.

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

Oh I see. Yes, this is one of the reasons I don't like the "pure can't
include non-pure" idea.

Another reason: you can't write generic algorithms. PHP 5.4 has much
improved support for anonymous functions, so we should see an increase
in libraries that take a few functions as parameters and carry out an
operation via those functions. But what if one of those functions
requires something from a .php file? Whoops, I guess it's not a
generic sorting algorithm library I just released, it's a "generic
sorting as long as none of your functions touch a .php file" algorithm
library. And good luck figuring this out when it happens.

Kris has pointed out that you could still load a .php file via a
function that was defined earlier in a .php file that later includes
.phpp. But this just means that, like my RFC, his RFC contains a
compromise about strictness. It's just that his compromise is more
confusing and less likely to be understood before the user gets
frustrated and declares the whole thing not worth messing with. I
think ".phpp files don't contain <?php and ?> but can require and
include files that do" is a much clearer compromise, one that will get
us what we want (an ever increasing percentage of .phpp files) without
making enemies and generating opposition along the way to that better
place.

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

16 апреля 2012 г. 16:09 пользователь Tom Boutell tom@punkave.com
написал:

These tools already strip <?php tags, they would need minimal changes
to
support rolling in a .phpp file unmodified. Unless I am missing
something?

Sent from my iPhone

On Apr 15, 2012, at 5:30 PM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

I posted the bellow text in other thread, but i should have it post
here,
so i'm reposting it to this thread.

Well, it's time for me to remind about the techique many use (and
some
frameworks provide it out of the box) - the application file
concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes
mostly
used core classes in one big file.that loads much faster and is used
for
production. Any other framework has user extentions or other type of
solutions for this to speed up the application, and it makes really
big
difference.
So there is a good question - how the hell in a MVC framework would i
combine my models, controllers, components and other stuff that will
definetly be as in .php so in .pphp. And not every file will be
cached
like
that - some will remain as distinct files even in production.

The further discussion goes the more questions there is and less
answers
there are.

Yes they obviously do, but that's not what I'm concerned about.
What I'm concerned is that code from .php and .pphp files get's mixed in
together - template engine related stuff is used as much, as do
controllers,
session handling classes and bunch of other stuff that by definition is
.pphp stuff, but the template stuff is .php and it includes templates.
So
basically everything just has to fall back to the embedded PHP mode to
work
and we have no gain from the proposal what so ever - it just becomes
useless.

That's not counting other issues that people and I have been voicing
and to
be honest, I never saw a reply to any of it. Maybe there is a reply to
all those questions, but they are under wall of text that usually goes
in
reply - that just discourages to read it at all.

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

--

The RFC is vague on these points because they haven't been determined yet,
though I am starting to lean toward the include/require parameter option
for includes.

To Tom's point, these questions have already been addressed. Basically,
there will be a third type that's on a per-file basis, designed to mitigate
the concerns that have been expressed over making this accessible to people
using certain frameworks that utilize tangled architecture. The per-stack
option will be more suitable for applications that have been designed from
the ground-up to use a seperated architecture. Though the per-file one
really wouldn't be useful for me, enough people believe that it will be.
So since there are valid use cases for both options, I'll include them both.

Please refer to my post on Pierre's thread. I outlined an idea for how
this could work syntactically. Please post your responses here though so
the thread will be easier to follow.

--Kris

13 years ago by Tom Boutell — view source

unread

Kris, you have been talking recently about allowing for a mode that
permits the inclusion of .php from .php... something (whatever we're
calling this middle mode's recommended file extension).

I think having three modes is overkill, but some people think having
even two modes is overkill, so I'm prepared to live with having all
three modes (traditional PHP, "pure" PHP that is allowed to include
traditional PHP, and "purest" PHP that is not allowed to include
traditional PHP).

After all, I don't have to use "purest" mode if I choose not to do so

and I suspect most library authors won't because they want to write
code that can include whatever the user wants it to. That's their
choice and mine, and there's really no reason to deny you the option
of "purest" mode.

And one can make the argument that while, as you say, model code
should never include a template, controller code (or classes in the
view layer that manage templates) should invoke templates. That would
give a better rationale for having all three types.

However, your RFC still does not address allowing all three and
currently includes very negative language about the middle option.

A second issue is that your RFC calls for file extensions to be
explicitly recognized by PHP itself, which is something many people
have objected to because the file extension may be unavailable or
irrelevant depending on the environment. That's why my RFC addresses
the file extension issue as a strongly recommended convention, not a
language feature, and provides keywords that can be used to implement
that convention (and really ought to provide options for the various
SAPIs as well, so entry points can be pure PHP if desired).

I think it's probably time to write an updated version of your RFC so
we can figure out if we're developing common ground here.

2012/4/16 Kris Craig kris.craig@gmail.com:

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

Also, Kris's proposal requires that an additional flag be tracked all
the way down through the stack of requires and includes from the point
where pure mode is first encountered, remembering that we're in pure
mode. Note that this flag cannot be a global variable because .php
files that were loaded before this .phpp file are still permitted to
load things, including when acting as autoloaders on behalf of .phpp
code... my head hurts. This cannot be the cleanest way to solve the
problem.

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

Oh I see. Yes, this is one of the reasons I don't like the "pure can't
include non-pure" idea.

Another reason: you can't write generic algorithms. PHP 5.4 has much
improved support for anonymous functions, so we should see an increase
in libraries that take a few functions as parameters and carry out an
operation via those functions. But what if one of those functions
requires something from a .php file? Whoops, I guess it's not a
generic sorting algorithm library I just released, it's a "generic
sorting as long as none of your functions touch a .php file" algorithm
library. And good luck figuring this out when it happens.

Kris has pointed out that you could still load a .php file via a
function that was defined earlier in a .php file that later includes
.phpp. But this just means that, like my RFC, his RFC contains a
compromise about strictness. It's just that his compromise is more
confusing and less likely to be understood before the user gets
frustrated and declares the whole thing not worth messing with. I
think ".phpp files don't contain <?php and ?> but can require and
include files that do" is a much clearer compromise, one that will get
us what we want (an ever increasing percentage of .phpp files) without
making enemies and generating opposition along the way to that better
place.

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

16 апреля 2012 г. 16:09 пользователь Tom Boutell tom@punkave.com
написал:

These tools already strip <?php tags, they would need minimal changes
to
support rolling in a .phpp file unmodified. Unless I am missing
something?

Sent from my iPhone

On Apr 15, 2012, at 5:30 PM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

I posted the bellow text in other thread, but i should have it post
here,
so i'm reposting it to this thread.

Well, it's time for me to remind about the techique many use (and
some
frameworks provide it out of the box) - the application file
concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes
mostly
used core classes in one big file.that loads much faster and is used
for
production. Any other framework has user extentions or other type of
solutions for this to speed up the application, and it makes really
big
difference.
So there is a good question - how the hell in a MVC framework would
i
combine my models, controllers, components and other stuff that will
definetly be as in .php so in .pphp. And not every file will be
cached
like
that - some will remain as distinct files even in production.

The further discussion goes the more questions there is and less
answers
there are.

Yes they obviously do, but that's not what I'm concerned about.
What I'm concerned is that code from .php and .pphp files get's mixed
in
together - template engine related stuff is used as much, as do
controllers,
session handling classes and bunch of other stuff that by definition is
.pphp stuff, but the template stuff is .php and it includes templates.
So
basically everything just has to fall back to the embedded PHP mode to
work
and we have no gain from the proposal what so ever - it just becomes
useless.

That's not counting other issues that people and I have been voicing
and to
be honest, I never saw a reply to any of it. Maybe there is a reply to
all those questions, but they are under wall of text that usually goes
in
reply - that just discourages to read it at all.

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

--

The RFC is vague on these points because they haven't been determined yet,
though I am starting to lean toward the include/require parameter option for
includes.

To Tom's point, these questions have already been addressed. Basically,
there will be a third type that's on a per-file basis, designed to mitigate
the concerns that have been expressed over making this accessible to people
using certain frameworks that utilize tangled architecture. The per-stack
option will be more suitable for applications that have been designed from
the ground-up to use a seperated architecture. Though the per-file one
really wouldn't be useful for me, enough people believe that it will be. So
since there are valid use cases for both options, I'll include them both.

Please refer to my post on Pierre's thread. I outlined an idea for how this
could work syntactically. Please post your responses here though so the
thread will be easier to follow.

--Kris

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

13 years ago by Kris Craig — view source

unread

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

Kris, you have been talking recently about allowing for a mode that
permits the inclusion of .php from .php... something (whatever we're
calling this middle mode's recommended file extension).

I think having three modes is overkill, but some people think having
even two modes is overkill, so I'm prepared to live with having all
three modes (traditional PHP, "pure" PHP that is allowed to include
traditional PHP, and "purest" PHP that is not allowed to include
traditional PHP).

After all, I don't have to use "purest" mode if I choose not to do so

and I suspect most library authors won't because they want to write
code that can include whatever the user wants it to. That's their
choice and mine, and there's really no reason to deny you the option
of "purest" mode.

And one can make the argument that while, as you say, model code
should never include a template, controller code (or classes in the
view layer that manage templates) should invoke templates. That would
give a better rationale for having all three types.

However, your RFC still does not address allowing all three and
currently includes very negative language about the middle option.

That's because I haven't updated it since the initial draft.

A second issue is that your RFC calls for file extensions to be
explicitly recognized by PHP itself, which is something many people
have objected to because the file extension may be unavailable or
irrelevant depending on the environment. That's why my RFC addresses
the file extension issue as a strongly recommended convention, not a
language feature, and provides keywords that can be used to implement
that convention (and really ought to provide options for the various
SAPIs as well, so entry points can be pure PHP if desired).

That's not actually true. What it's referring to is a convention and
distinguishing between file extensions when accessed via the webserver.
This is already the current behavior via handlers; the RFC isn't actually
proposing to parse the filename itself at the langugage level. Though
seeing as how you're the second person to have misinterpreted it to mean
that, it's possible that the wording I used wasn't clear enough on that
point.

I think it's probably time to write an updated version of your RFC so
we can figure out if we're developing common ground here.

I was hoping to get a little more clarification on the inclusion method at
the language level before proceeding with that. Specifically, is everybody
good with using include/require as $bitwise_constant? Or do people still
think the other options need to be debated more first?

--Kris

2012/4/16 Kris Craig kris.craig@gmail.com:

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

Also, Kris's proposal requires that an additional flag be tracked all
the way down through the stack of requires and includes from the point
where pure mode is first encountered, remembering that we're in pure
mode. Note that this flag cannot be a global variable because .php
files that were loaded before this .phpp file are still permitted to
load things, including when acting as autoloaders on behalf of .phpp
code... my head hurts. This cannot be the cleanest way to solve the
problem.

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

Oh I see. Yes, this is one of the reasons I don't like the "pure can't
include non-pure" idea.

Another reason: you can't write generic algorithms. PHP 5.4 has much
improved support for anonymous functions, so we should see an increase
in libraries that take a few functions as parameters and carry out an
operation via those functions. But what if one of those functions
requires something from a .php file? Whoops, I guess it's not a
generic sorting algorithm library I just released, it's a "generic
sorting as long as none of your functions touch a .php file" algorithm
library. And good luck figuring this out when it happens.

Kris has pointed out that you could still load a .php file via a
function that was defined earlier in a .php file that later includes
.phpp. But this just means that, like my RFC, his RFC contains a
compromise about strictness. It's just that his compromise is more
confusing and less likely to be understood before the user gets
frustrated and declares the whole thing not worth messing with. I
think ".phpp files don't contain <?php and ?> but can require and
include files that do" is a much clearer compromise, one that will get
us what we want (an ever increasing percentage of .phpp files) without
making enemies and generating opposition along the way to that better
place.

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

16 апреля 2012 г. 16:09 пользователь Tom Boutell tom@punkave.com
написал:

These tools already strip <?php tags, they would need minimal
changes
to
support rolling in a .phpp file unmodified. Unless I am missing
something?

Sent from my iPhone

On Apr 15, 2012, at 5:30 PM, Arvids Godjuks <
arvids.godjuks@gmail.com>
wrote:

I posted the bellow text in other thread, but i should have it
post
here,
so i'm reposting it to this thread.

Well, it's time for me to remind about the techique many use (and
some
frameworks provide it out of the box) - the application file
concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes
mostly
used core classes in one big file.that loads much faster and is
used
for
production. Any other framework has user extentions or other type
of
solutions for this to speed up the application, and it makes
really
big
difference.
So there is a good question - how the hell in a MVC framework
would
i
combine my models, controllers, components and other stuff that
will
definetly be as in .php so in .pphp. And not every file will be
cached
like
that - some will remain as distinct files even in production.

The further discussion goes the more questions there is and less
answers
there are.

Yes they obviously do, but that's not what I'm concerned about.
What I'm concerned is that code from .php and .pphp files get's mixed
in
together - template engine related stuff is used as much, as do
controllers,
session handling classes and bunch of other stuff that by definition
is
.pphp stuff, but the template stuff is .php and it includes
templates.
So
basically everything just has to fall back to the embedded PHP mode
to
work
and we have no gain from the proposal what so ever - it just becomes
useless.

That's not counting other issues that people and I have been voicing
and to
be honest, I never saw a reply to any of it. Maybe there is a reply
to
all those questions, but they are under wall of text that usually
goes
in
reply - that just discourages to read it at all.

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

--

The RFC is vague on these points because they haven't been determined
yet,
though I am starting to lean toward the include/require parameter option
for
includes.

To Tom's point, these questions have already been addressed. Basically,
there will be a third type that's on a per-file basis, designed to
mitigate
the concerns that have been expressed over making this accessible to
people
using certain frameworks that utilize tangled architecture. The
per-stack
option will be more suitable for applications that have been designed
from
the ground-up to use a seperated architecture. Though the per-file one
really wouldn't be useful for me, enough people believe that it will
be. So
since there are valid use cases for both options, I'll include them both.

Please refer to my post on Pierre's thread. I outlined an idea for how
this
could work syntactically. Please post your responses here though so the
thread will be easier to follow.

--Kris

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

13 years ago by Tom Boutell — view source

unread

I think updating your RFC to cover the broad points that have changed
is worth it, even if small differences will continue to be expressed
about the syntax.

2012/4/16 Kris Craig kris.craig@gmail.com:

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

Kris, you have been talking recently about allowing for a mode that
permits the inclusion of .php from .php... something (whatever we're
calling this middle mode's recommended file extension).

I think having three modes is overkill, but some people think having
even two modes is overkill, so I'm prepared to live with having all
three modes (traditional PHP, "pure" PHP that is allowed to include
traditional PHP, and "purest" PHP that is not allowed to include
traditional PHP).

After all, I don't have to use "purest" mode if I choose not to do so

and I suspect most library authors won't because they want to write
code that can include whatever the user wants it to. That's their
choice and mine, and there's really no reason to deny you the option
of "purest" mode.

And one can make the argument that while, as you say, model code
should never include a template, controller code (or classes in the
view layer that manage templates) should invoke templates. That would
give a better rationale for having all three types.

However, your RFC still does not address allowing all three and
currently includes very negative language about the middle option.

That's because I haven't updated it since the initial draft.

A second issue is that your RFC calls for file extensions to be
explicitly recognized by PHP itself, which is something many people
have objected to because the file extension may be unavailable or
irrelevant depending on the environment. That's why my RFC addresses
the file extension issue as a strongly recommended convention, not a
language feature, and provides keywords that can be used to implement
that convention (and really ought to provide options for the various
SAPIs as well, so entry points can be pure PHP if desired).

That's not actually true. What it's referring to is a convention and
distinguishing between file extensions when accessed via the webserver.
This is already the current behavior via handlers; the RFC isn't actually
proposing to parse the filename itself at the langugage level. Though
seeing as how you're the second person to have misinterpreted it to mean
that, it's possible that the wording I used wasn't clear enough on that
point.

I think it's probably time to write an updated version of your RFC so
we can figure out if we're developing common ground here.

I was hoping to get a little more clarification on the inclusion method at
the language level before proceeding with that. Specifically, is everybody
good with using include/require as $bitwise_constant? Or do people still
think the other options need to be debated more first?

--Kris

2012/4/16 Kris Craig kris.craig@gmail.com:

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

Also, Kris's proposal requires that an additional flag be tracked all
the way down through the stack of requires and includes from the point
where pure mode is first encountered, remembering that we're in pure
mode. Note that this flag cannot be a global variable because .php
files that were loaded before this .phpp file are still permitted to
load things, including when acting as autoloaders on behalf of .phpp
code... my head hurts. This cannot be the cleanest way to solve the
problem.

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

Oh I see. Yes, this is one of the reasons I don't like the "pure
can't
include non-pure" idea.

Another reason: you can't write generic algorithms. PHP 5.4 has much
improved support for anonymous functions, so we should see an
increase
in libraries that take a few functions as parameters and carry out an
operation via those functions. But what if one of those functions
requires something from a .php file? Whoops, I guess it's not a
generic sorting algorithm library I just released, it's a "generic
sorting as long as none of your functions touch a .php file"
algorithm
library. And good luck figuring this out when it happens.

Kris has pointed out that you could still load a .php file via a
function that was defined earlier in a .php file that later includes
.phpp. But this just means that, like my RFC, his RFC contains a
compromise about strictness. It's just that his compromise is more
confusing and less likely to be understood before the user gets
frustrated and declares the whole thing not worth messing with. I
think ".phpp files don't contain <?php and ?> but can require and
include files that do" is a much clearer compromise, one that will
get
us what we want (an ever increasing percentage of .phpp files)
without
making enemies and generating opposition along the way to that better
place.

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

16 апреля 2012 г. 16:09 пользователь Tom Boutell tom@punkave.com
написал:

These tools already strip <?php tags, they would need minimal
changes
to
support rolling in a .phpp file unmodified. Unless I am missing
something?

Sent from my iPhone

On Apr 15, 2012, at 5:30 PM, Arvids Godjuks
arvids.godjuks@gmail.com
wrote:

I posted the bellow text in other thread, but i should have it
post
here,
so i'm reposting it to this thread.

Well, it's time for me to remind about the techique many use (and
some
frameworks provide it out of the box) - the application file
concatination
to speed up file loading.
Yii framework provides a Yiilite.php file for this, that includes
mostly
used core classes in one big file.that loads much faster and is
used
for
production. Any other framework has user extentions or other type
of
solutions for this to speed up the application, and it makes
really
big
difference.
So there is a good question - how the hell in a MVC framework
would
i
combine my models, controllers, components and other stuff that
will
definetly be as in .php so in .pphp. And not every file will be
cached
like
that - some will remain as distinct files even in production.

The further discussion goes the more questions there is and less
answers
there are.

Yes they obviously do, but that's not what I'm concerned about.
What I'm concerned is that code from .php and .pphp files get's
mixed
in
together - template engine related stuff is used as much, as do
controllers,
session handling classes and bunch of other stuff that by definition
is
.pphp stuff, but the template stuff is .php and it includes
templates.
So
basically everything just has to fall back to the embedded PHP mode
to
work
and we have no gain from the proposal what so ever - it just becomes
useless.

That's not counting other issues that people and I have been voicing
and to
be honest, I never saw a reply to any of it. Maybe there is a reply
to
all those questions, but they are under wall of text that usually
goes
in
reply - that just discourages to read it at all.

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

--

The RFC is vague on these points because they haven't been determined
yet,
though I am starting to lean toward the include/require parameter option
for
includes.

To Tom's point, these questions have already been addressed. Basically,
there will be a third type that's on a per-file basis, designed to
mitigate
the concerns that have been expressed over making this accessible to
people
using certain frameworks that utilize tangled architecture. The
per-stack
option will be more suitable for applications that have been designed
from
the ground-up to use a seperated architecture. Though the per-file one
really wouldn't be useful for me, enough people believe that it will
be. So
since there are valid use cases for both options, I'll include them
both.

Please refer to my post on Pierre's thread. I outlined an idea for how
this
could work syntactically. Please post your responses here though so the
thread will be easier to follow.

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

unread

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

I think updating your RFC to cover the broad points that have changed
is worth it, even if small differences will continue to be expressed
about the syntax.

Hmm ok, I'll update it first chance I get. Keep in mind though it might
still be a few days as I work during the week.

--Kris

[RFC] New .phpp File Type for Pure-Code PHP Scripts

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL