Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59913
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <B6.A1.11739.066888F4@pb1.pair.com>
References: <CAKOpQSwYe+tZ3JfLFWaOHCnBpUyy9yoA61=qLzbnnOKTL0mQdQ@mail.gmail.com>
	<CAGa2bXa554p45tbNFvtHQJiYTXaa0eD6r+qnExDVk+6e8PRvMw@mail.gmail.com>
	<4F876943.8030105@gmail.com>
	<CAKOpQSzAZauE9HYK3x-5UbxAstkdkc-HkfZRa+E+i=DNxQwkBA@mail.gmail.com>
	<4F877777.8050806@gmail.com>
	<CAKOpQSyC6Zs=3-AQ8=L-aufTP03j0yhnRiu3n6pNP7YSpW_KLg@mail.gmail.com>
	<4F8782CC.8030205@gmail.com>
	<CAKOpQSzKo9ZX1voYppTRihkfkpfCywMLLv_DF8XWGxcOV1Su8Q@mail.gmail.com>
	<CAGsnKxaR8vHHeZrpDhf4WVBKqDwMXrAf=b=3r06oJZpP4K3sPg@mail.gmail.com>
	<CAKOpQSyVu3ddZubCeo4BpZTWFXf55_yYNbrhDqTJkDjPoX6xVw@mail.gmail.com>
	<CAGsnKxatwB-T5ExGjq9z0FyjhRB0DKVRigu=opqXbjoyUAcwRA@mail.gmail.com>
	<CAKOpQSy3BVpY-UNSvVkQSoPBV=ZKdiJ0nOC14ou3YRdJM5XmnQ@mail.gmail.com>
	<13.6A.35770.615388F4@pb1.pair.com>
	<CAKOpQSznwqVb_iVoKf76dswWwL4OGa4Zj8C+iYj+W4RUrMErTg@mail.gmail.com>
	<A633CF2D7C7BED41B41F1E64F25507B806A5CDD8B5@MAILR001.mail.lan>
	<CAKOpQSyLtAkX6ZHmSjkcEg6OohE7Mppm91yGwusUN80kyr1ptg@mail.gmail.com>
	<B6.A1.11739.066888F4@pb1.pair.com>
Date: Fri, 13 Apr 2012 13:19:52 -0700
Message-ID: <CAKOpQSw+ifiY1OQaNt15mxX257c1vkXU+0s6nPcYPLtG8Nc4EQ@mail.gmail.com>
To: "Matthew Weier O'Phinney" <weierophinney@php.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=f46d04182638f771a804bd953154
Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
From: kris.craig@gmail.com (Kris Craig)

--f46d04182638f771a804bd953154
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 13, 2012 at 1:02 PM, Matthew Weier O'Phinney <
weierophinney@php.net> wrote:

> On 2012-04-13, Kris Craig <kris.craig@gmail.com> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f46d04182638f771a804bd953154--