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
