Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Pure PHP Scripts (Updated) »

[RFC] Pure PHP Scripts (Updated)

php.internals

Kris Craig

14 years ago
Hi all, I finally found some time today to update the RFC based on discussions here. Please have a look and let me know if I missed anything or if there's anything else that needs clarifying: https://wiki.php.net/rfc/phpp I also want to know if this is sufficient to satisfy some of the concerns that have been raised about being able to implement this into existing frameworks that use a more "tangled" architecture. Thanks! =) --Kris

Tom Boutell

14 years ago
* The RFC starts off immediately talking about file extensions, but the actual implementation proposed doesn't rely on file extensions or suggest any enforcement of them. That disparity should be addressed for clarity. * The RFC quotes an entire discussion with a lot of harsh language about coding practices that are currently considered standard in most MVC frameworks, including the original message you were responding to (which happened to be mine). I am not sure you intended to leave all that in. In general that discussion contradicts the work you've done elsewhere in the RFC to propose both .phpp and .phpf. On Tue, Apr 24, 2012 at 3:52 PM, Kris Craig <kris.craig@gmail.com> wrote:
> Hi all, > > I finally found some time today to update the RFC based on discussions > here.  Please have a look and let me know if I missed anything or if > there's anything else that needs clarifying: > > https://wiki.php.net/rfc/phpp > > > I also want to know if this is sufficient to satisfy some of the concerns > that have been raised about being able to implement this into existing > frameworks that use a more "tangled" architecture. > > Thanks!  =) > > --Kris
-- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com

Kris Craig

14 years ago
On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell <tom@punkave.com> wrote:
> * The RFC starts off immediately talking about file extensions, but > the actual implementation proposed doesn't rely on file extensions or > suggest any enforcement of them. That disparity should be addressed > for clarity. >
Did you read the whole RFC? Please refer to the "Naming Conventions" section. It addresses this explicitly. Are you saying that section wasn't sufficiently clear or did you just miss it?
> > * The RFC quotes an entire discussion with a lot of harsh language > about coding practices that are currently considered standard in most > MVC frameworks, including the original message you were responding to > (which happened to be mine). I am not sure you intended to leave all > that in. In general that discussion contradicts the work you've done > elsewhere in the RFC to propose both .phpp and .phpf. >
Could you elaborate? The only thing from the Internals discussion I actually copy/pasted was the example I posted pertaining to the bitwise constant; it was very technical in nature and didn't contain any harsh language that I could see. Or are you referring to something else? If so, please let me know what it is and I can fix it.

Tjerk Meesters

14 years ago
On 25 Apr, 2012, at 5:42 AM, Kris Craig <kris.craig@gmail.com> wrote:
> On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell <tom@punkave.com> wrote: > >> * The RFC starts off immediately talking about file extensions, but >> the actual implementation proposed doesn't rely on file extensions or >> suggest any enforcement of them. That disparity should be addressed >> for clarity. >> > > Did you read the whole RFC? Please refer to the "Naming Conventions" > section. It addresses this explicitly. > > Are you saying that section wasn't sufficiently clear or did you just miss > it? >
I think what he means is that the abstract section should be, well, abstract. Currently it appears more detailed than it should be by referring to file extensions on the let go. I would phrase that section in a way that doesn't rely on another section to explain the used terminology. Also, references such as .phpp are used throughout the document to indicate a particular type of source file rather than an actual file extension. As such I would recommend moving your terminology section to right underneath abstract. This would improve the readability.

Kris Craig

14 years ago
On Tue, Apr 24, 2012 at 4:00 PM, Tjerk Meesters <tjerk.meesters@gmail.com>wrote:
> > On 25 Apr, 2012, at 5:42 AM, Kris Craig <kris.craig@gmail.com> wrote: > > > On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell <tom@punkave.com> wrote: > > > >> * The RFC starts off immediately talking about file extensions, but > >> the actual implementation proposed doesn't rely on file extensions or > >> suggest any enforcement of them. That disparity should be addressed > >> for clarity. > >> > > > > Did you read the whole RFC? Please refer to the "Naming Conventions" > > section. It addresses this explicitly. > > > > Are you saying that section wasn't sufficiently clear or did you just > miss > > it? > > > > I think what he means is that the abstract section should be, well, > abstract. Currently it appears more detailed than it should be by referring > to file extensions on the let go. I would phrase that section in a way that > doesn't rely on another section to explain the used terminology. > > Also, references such as .phpp are used throughout the document to > indicate a particular type of source file rather than an actual file > extension. As such I would recommend moving your terminology section to > right underneath abstract. This would improve the readability. > >
Hmm I see your point. Ok I'll update that langauge next time I can find a spare moment. So aside from that, what are your thoughts? In addition to feedback on the wording itself, I'd also be interested in hearing your thoughts on the actual amended proposal itself. Does the new script type alleviate your main concerns about frameworks (keeping in mind that a compromise is a solution that neither party likes but both parties can live with)? What do you think about the require/include syntax suggestions? Should it be comma-delinated or use "as" instead? Etc. Thanks! --Kris

Tom Boutell

14 years ago
Please review the section titled "Inclusion of Mixed Code," which contains the quoted conversation I referred to, with commentary about "bad, lazy" architecture that is currently standard in numerous frameworks. I understand that you feel that in future such frameworks will make a different set of choices, but it still doesn't make sense to import that old thread of argument into your RFC directly. I think you mean to present the diagram only, with a more dispassionate explanation of its purpose. On Tue, Apr 24, 2012 at 7:27 PM, Kris Craig <kris.craig@gmail.com> wrote:
> > > On Tue, Apr 24, 2012 at 4:00 PM, Tjerk Meesters <tjerk.meesters@gmail.com> > wrote: >> >> >> On 25 Apr, 2012, at 5:42 AM, Kris Craig <kris.craig@gmail.com> wrote: >> >> > On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell <tom@punkave.com> wrote: >> > >> >> * The RFC starts off immediately talking about file extensions, but >> >> the actual implementation proposed doesn't rely on file extensions or >> >> suggest any enforcement of them. That disparity should be addressed >> >> for clarity. >> >> >> > >> > Did you read the whole RFC?  Please refer to the "Naming Conventions" >> > section.  It addresses this explicitly. >> > >> > Are you saying that section wasn't sufficiently clear or did you just >> > miss >> > it? >> > >> >> I think what he means is that the abstract section should be, well, >> abstract. Currently it appears more detailed than it should be by referring >> to file extensions on the let go. I would phrase that section in a way that >> doesn't rely on another section to explain the used terminology. >> >> Also, references such as .phpp are used throughout the document to >> indicate a particular type of source file rather than an actual file >> extension. As such I would recommend moving your terminology section to >> right underneath abstract. This would improve the readability. >> > > Hmm I see your point.  Ok I'll update that langauge next time I can find a > spare moment. > > So aside from that, what are your thoughts?  In addition to feedback on the > wording itself, I'd also be interested in hearing your thoughts on the > actual amended proposal itself.  Does the new script type alleviate your > main concerns about frameworks (keeping in mind that a compromise is a > solution that neither party likes but both parties can live with)?  What do > you think about the require/include syntax suggestions?  Should it be > comma-delinated or use "as" instead?  Etc. > > Thanks! > > --Kris >
-- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com

Kris Craig

14 years ago
On Tue, Apr 24, 2012 at 5:54 PM, Tom Boutell <tom@punkave.com> wrote:
> Please review the section titled "Inclusion of Mixed Code," which > contains the quoted conversation I referred to, with commentary about > "bad, lazy" architecture that is currently standard in numerous > frameworks. I understand that you feel that in future such frameworks > will make a different set of choices, but it still doesn't make sense > to import that old thread of argument into your RFC directly. I think > you mean to present the diagram only, with a more dispassionate > explanation of its purpose.
Ahh ok, yeah I think I pretty much just left that section as-is. I'll go ahead and fix that. --Kris

Arvids Godjuks

14 years ago
As far as I read there is no difference from the previous RFC - it says essentially the same. " The <?php tag, contained within one of these files, tells the webserver to, in essence, “switch to PHP mode” and start parsing the data as PHP code. When the ?> tag is reached, the webserver “switches back” and resumes parsing it as HTML. If no tags are given, the webserver will parse the file data as HTML code until a <?php tag is reached. " I'm I the only one who thinks that this is just plain wrong? I know for a fact that there is no "PHP mode" on the WEB server level. I think I understand what it tries to say, but I totally disagree with what is written and don't want to guess anything. 24 апреля 2012 г. 22:52 пользователь Kris Craig <kris.craig@gmail.com>написал:

Tom Boutell

14 years ago
That's a good point, it should say the PHP tokenizer, or something to that effect (folks who spend more time with the internals could say better what to call it). The major difference from his previous version of the RFC is his addition of the .phpf format, which would allow including a .php file with <?php and ?> in it from a .phpf file, but would not allow or need any usage of <?php and ?> within the .phpf file itself. On Tue, Apr 24, 2012 at 4:14 PM, Arvids Godjuks <arvids.godjuks@gmail.com> wrote:
> As far as I read there is no difference from the previous RFC - it > says essentially the same. > > " The <?php tag, contained within one of these files, tells the webserver > to, in essence, "switch to PHP mode" and start parsing the data as PHP code. > When the ?> tag is reached, the webserver "switches back" and resumes > parsing it as HTML. If no tags are given, the webserver will parse the file > data as HTML code until a <?php tag is reached. " > > I'm I the only one who thinks that this is just plain wrong? I know for a > fact that there is no "PHP mode" on the WEB server level. I think I > understand what it tries to say, but I totally disagree with what is > written and don't want to guess anything. > > 24 апреля 2012 г. 22:52 пользователь Kris Craig <kris.craig@gmail.com>написал: > >> Hi all, >> >> I finally found some time today to update the RFC based on discussions >> here. Please have a look and let me know if I missed anything or if >> there's anything else that needs clarifying: >> >> https://wiki.php.net/rfc/phpp >> >> >> I also want to know if this is sufficient to satisfy some of the concerns >> that have been raised about being able to implement this into existing >> frameworks that use a more "tangled" architecture. >> >> Thanks! =) >> >> --Kris >>
-- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com

Kris Craig

14 years ago
2012/4/24 Tom Boutell <tom@punkave.com>
> That's a good point, it should say the PHP tokenizer, or something to > that effect (folks who spend more time with the internals could say > better what to call it). >
Hmm yeah I guess that wording is a bit sloppy, isn't it? I'm not sure what the "proper" terminology would be there. Any suggestions?
> > The major difference from his previous version of the RFC is his > addition of the .phpf format, which would allow including a .php file > with <?php and ?> in it from a .phpf file, but would not allow or need > any usage of <?php and ?> within the .phpf file itself. >
Partially correct. That is the only practical difference, but I also added clarifying language based on concerns raised here. For example, I added a section clarifying that the references to a file extension are merely a convention and do not represent a new parsing method based on filename. I also added clarifications on how script inclusion would work vs. direct access via URL on a webserver.