Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59731
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.216.170 as permitted sender)
References: <CAORXhGK47pRN8uUTENqSbddQoCP8VopomPhJW7N2pN6ZU8vNPQ@mail.gmail.com> <CAKOpQSz5tdkHK=MVsC8+8oL+Q-TGDAP=uBBC=i0p0pSJ4mn38Q@mail.gmail.com> <CAORXhGLppTWU9nRfhWLwRtHK_ct4SSLJxpwqAM0g6cnNirPSHA@mail.gmail.com> <CAKOpQSzg5h539E341b5fyyUPj86Lf=E=r8B28PXrLcsj9O4RDw@mail.gmail.com> <CAORXhGKwaCv-YoQ6TgEshtE2KQd0d_f8jrz3qYRDustA2eA58A@mail.gmail.com> <CAKOpQSyccBgWaaPKRc1Nzo9kLgTcFxNmsKBxgZokjP+vmqeR+g@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary=Apple-Mail-FE13DDB6-C32D-4C71-8B23-A7FF70B63C12
In-Reply-To: <CAKOpQSyccBgWaaPKRc1Nzo9kLgTcFxNmsKBxgZokjP+vmqeR+g@mail.gmail.com>
Message-ID: <670CAF9F-E53D-45EE-9A46-9F7891B76A26@punkave.com>
Date: Wed, 11 Apr 2012 08:07:31 -0400
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening <?php tag
From: tom@punkave.com (Tom Boutell)

--Apple-Mail-FE13DDB6-C32D-4C71-8B23-A7FF70B63C12
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I had no goal of making sure code "remains pure" in this rfc, only the goal o=
f being allowed to write pure code (no opening <?php ) and establishing a wa=
y to encourage pure code in the scope of individual class files (disallowing=
 ?> in individual pure mode files). I think an easy, obvious bc mechanism is=
 essential, making it harder to use legacy code is not something people woul=
d vote for, and more pure code is better than no pure code. You feel differe=
ntly. I'm not sure our positions can be reconciled. Perhaps this point will j=
ust have to be settled when the rfc is voted on.

Sent from my iPhone

On Apr 11, 2012, at 1:16 AM, Kris Craig <kris.craig@gmail.com> wrote:

>=20
>=20
> On Tue, Apr 10, 2012 at 8:35 PM, Tom Boutell <tom@punkave.com> wrote:
> On Tue, Apr 10, 2012 at 10:10 PM, Kris Craig <kris.craig@gmail.com> wrote:=

> > This shouldn't be used to load libraries that dump raw HTML output!  Tha=
t
> > literally defeats the entire purpose.  You're also assuming that all PHP=

> > developers do 100% of their coding through pre-existing frameworks.
>=20
> Consider a .phpp file that includes a .php template file when it sees
> fit, in a render() method. How is this different from an echo()
> statement? It's not. It's just a convenient form in some situations.
> By punting these out to .php files we achieve better separation of
> concerns while still respecting PHP's history as a template language
> (and possible future if it improves in that area, which it may).
>=20
> Again, this can easily be made to work using a simple MVC architecture.  I=
.e. the "view" layer calls controller::render(), which then includes model.p=
hpp and funnels the call to model::render().  Again, this is just basic segr=
egation of model (i.e. "pure") code from view (i.e. template) code.  This is=
 already widely considered best practices, so having this conform to that is=
 not a bad thing.  On the other hand, your approach makes it impossible to d=
etermine absolutely that the model code will remain pure, thus rendering thi=
s whole RFC completely and utterly useless IMHO.
>=20
>=20
> All I want is to stop typing <?php and dealing with whitespace
> screwups above <?php. I want to do that in a way that's practical and
> interoperable and which people might be able to vote for if they have
> a nontrivial amount of legacy code in their life, like everybody I
> work with (:
>=20
> I know.  But unfortunately, for reasons already discussed ad nauseum, the o=
nly way to truly accomplish that without weighing other factors would be to m=
assively break all PHP scripts that currently exist.  You may want to just h=
ave a simple removal of <?php, but it's not that simple so you should probab=
ly adjust your expectations accordingly.
> =20
>=20
> As many have pointed out, plain php template files work for some
> projects. A viable RFC that people might actually vote for should
> respect that. It neither picks my pocket nor breaks my leg if someone
> wants to include .php template files from a .phpp file. I don't have
> to do it.
>=20
> Again, if you're concerned about that, then you have no business including=
 them within a .phpp file to begin with.  It's basically like turning on the=
 shower but then covering the nozzle with a stopper so that no water will co=
me out, allowing you to "take a shower" while still remaining dirty.  If you=
 want to stay covered in dirt, then don't take a shower!  If you do take a s=
hower, then you have no business doing so if your goal isn't to get clean.  T=
hat would just make no sense.
>=20
>=20
> When you consider that I would be completely unable to use an existing
> .php library of nontrival code like Amazon's S3 SDK under your
> proposal without a convoluted workaround it is pretty much a certainty
> that I would have to vote no if the RFC read that way.
>=20
> That's a logical fallacy because it's based on a faulty premise.  I.e. "..=
..I would be completely unable to use....  without a convoluted workaround..=
.."
>=20
> That statement is inaccurate because there is no "workaround," convoluted o=
r otherwise.  It's just standard MVC architecture, which is neither convolut=
ed nor uncommon.  If somebody wanted to be able to write a script containing=
 class instantiation but keep the code 100% procedural, most people would te=
ll that person to rethink that idea.  He could say that having to define a c=
lass is a "convoluted workaround," but it's not.
>=20
> Instead of having your .phpp script call a script containing HTML, and thu=
s essentially having your .phpp file contain HTML and thus be no different o=
n a practical level than a regular .php file, just have a regular .php scrip=
t that calls both the .phpp file and the .php library.  That's not complicat=
ed.  In fact, it's insultingly simple.  If you want it to be pure PHP, then i=
t needs to be pure PHP throughout its stack (i.e. includes).  Either way, it=
 needs to be consistent.  Your approach would add far too much complexity/co=
nfusion without any practical gain, whatsoever (aside from not having to typ=
e that 5-character <?php tag).
> =20
>=20
> >                 (Main Script)
> >                      |
> >                      |
> >          [Included .php/HTML Script]
> >              |                   |
> >              |                   |
> > {Included .phpp Script}      [Included .php/HTML Script from
> > Framework/Library]
>=20
> This is convoluted and forces me to write a .php frontend. Surely that
> is not your goal.
>=20
> I think the problem is you're trying to have it both ways.  No, you are no=
t forced to write a .php frontend.  You can send whatever HTML/template outp=
ut you need through echo/print/etc, without ever having to use the ?> tag.
>=20
> Furthermore, if you're including a library with HTML bits, then I'd say th=
e ship has already sailed with regard to having a .php frontend.  If you don=
't wany any .php frontend in your code, then simply don't use a library that=
 relies on it.  Simple as that.  If you so want to include the library, then=
 simply make sure that there are no .php/HTML frontend files below it in the=
 stack, which is what you should be doing anyway.
>=20
> Also, the model above is just one example, and it's not complicated.  In f=
act, it contains all the same stuff as the bad example model above it; the o=
nly difference is that the .php and .phpp scripts are on the same level inst=
ead of .phpp calling a .php file that contains raw HTML code.
>=20
>=20
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20
>=20

--Apple-Mail-FE13DDB6-C32D-4C71-8B23-A7FF70B63C12--