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:
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
-
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.
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: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
- 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.
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: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
- 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.
On Tue, Apr 24, 2012 at 4:00 PM, Tjerk Meesters tjerk.meesters@gmail.comwrote:
- 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
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 4:00 PM, Tjerk Meesters tjerk.meesters@gmail.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
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
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: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
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: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
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.
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: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