[PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Kris Craig
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


Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Tom Boutell
* 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.cr...@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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Arvids Godjuks
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.cr...@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



Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Tom Boutell
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.godj...@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.cr...@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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Kris Craig
On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell t...@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.



 On Tue, Apr 24, 2012 at 3:52 PM, Kris Craig kris.cr...@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

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Kris Craig
2012/4/24 Tom Boutell t...@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.godj...@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.cr...@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

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Tjerk Meesters

On 25 Apr, 2012, at 5:42 AM, Kris Craig kris.cr...@gmail.com wrote:

 On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell t...@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. 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Kris Craig
On Tue, Apr 24, 2012 at 4:00 PM, Tjerk Meesters tjerk.meest...@gmail.comwrote:


 On 25 Apr, 2012, at 5:42 AM, Kris Craig kris.cr...@gmail.com wrote:

  On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell t...@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


Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Tom Boutell
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.cr...@gmail.com wrote:


 On Tue, Apr 24, 2012 at 4:00 PM, Tjerk Meesters tjerk.meest...@gmail.com
 wrote:


 On 25 Apr, 2012, at 5:42 AM, Kris Craig kris.cr...@gmail.com wrote:

  On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell t...@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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [RFC] Pure PHP Scripts (Updated)

2012-04-24 Thread Kris Craig
On Tue, Apr 24, 2012 at 5:54 PM, Tom Boutell t...@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