On 2012-04-13, Kris Craig <kris.cr...@gmail.com> wrote:
> --f46d04447f47ae95ec04bd949e5f
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw <johncrens...@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.
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.
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. 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.
--
Matthew Weier O'Phinney
Project Lead | matt...@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
