Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59743
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <670CAF9F-E53D-45EE-9A46-9F7891B76A26@punkave.com>
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>
	<670CAF9F-E53D-45EE-9A46-9F7891B76A26@punkave.com>
Date: Wed, 11 Apr 2012 10:57:01 -0700
Message-ID: <CAKOpQSxhmU4yPj0GtybeMdZ4=nrdYdqUDQ4qHYpFRA1m3KJmNw@mail.gmail.com>
To: Tom Boutell <tom@punkave.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0438934762420804bd6af75b
Subject: Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening
 <?php tag
From: kris.craig@gmail.com (Kris Craig)

--f46d0438934762420804bd6af75b
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 11, 2012 at 5:07 AM, Tom Boutell <tom@punkave.com> wrote:

> I had no goal of making sure code "remains pure" in this rfc, only the
> goal of being allowed to write pure code (no opening <?php ) and
> establishing a way 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 would vote for, and more pure code is better than no
> pure code. You feel differently. I'm not sure our positions can be
> reconciled. Perhaps this point will just have to be settled when the rfc is
> voted on.
>

Indeed.  Looks like I'll just have to draft an RFC of my own then.  So now
that will make 3 competing RFCs on this subject....  *grumble*


>
> Sent from my iPhone
>
> On Apr 11, 2012, at 1:16 AM, Kris Craig <kris.craig@gmail.com> wrote:
>
> >
> >
> > 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!
>  That
> > > literally defeats the entire purpose.  You're also assuming that all
> PHP
> > > developers do 100% of their coding through pre-existing frameworks.
> >
> > 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).
> >
> > 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.phpp and funnels the call to model::render().  Again, this is just
> basic segregation 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 determine absolutely that the model code will remain pure,
> thus rendering this whole RFC completely and utterly useless IMHO.
> >
> >
> > 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 (:
> >
> > I know.  But unfortunately, for reasons already discussed ad nauseum,
> the only way to truly accomplish that without weighing other factors would
> be to massively break all PHP scripts that currently exist.  You may want
> to just have a simple removal of <?php, but it's not that simple so you
> should probably adjust your expectations accordingly.
> >
> >
> > 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.
> >
> > 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 come 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 shower, then you have no business doing so if
> your goal isn't to get clean.  That would just make no sense.
> >
> >
> > 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.
> >
> > 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...."
> >
> > That statement is inaccurate because there is no "workaround,"
> convoluted or otherwise.  It's just standard MVC architecture, which is
> neither convoluted nor uncommon.  If somebody wanted to be able to write a
> script containing class instantiation but keep the code 100% procedural,
> most people would tell that person to rethink that idea.  He could say that
> having to define a class is a "convoluted workaround," but it's not.
> >
> > Instead of having your .phpp script call a script containing HTML, and
> thus essentially having your .phpp file contain HTML and thus be no
> different on a practical level than a regular .php file, just have a
> regular .php script that calls both the .phpp file and the .php library.
>  That's not complicated.  In fact, it's insultingly simple.  If you want it
> to be pure PHP, then it 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/confusion without any practical gain, whatsoever
> (aside from not having to type that 5-character <?php tag).
> >
> >
> > >                 (Main Script)
> > >                      |
> > >                      |
> > >          [Included .php/HTML Script]
> > >              |                   |
> > >              |                   |
> > > {Included .phpp Script}      [Included .php/HTML Script from
> > > Framework/Library]
> >
> > This is convoluted and forces me to write a .php frontend. Surely that
> > is not your goal.
> >
> > I think the problem is you're trying to have it both ways.  No, you are
> not forced to write a .php frontend.  You can send whatever HTML/template
> output you need through echo/print/etc, without ever having to use the ?>
> tag.
> >
> > Furthermore, if you're including a library with HTML bits, then I'd say
> the 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.
> >
> > Also, the model above is just one example, and it's not complicated.  In
> fact, it contains all the same stuff as the bad example model above it; the
> only difference is that the .php and .phpp scripts are on the same level
> instead of .phpp calling a .php file that contains raw HTML code.
> >
> >
> > --
> > 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
> >
> >
>

--f46d0438934762420804bd6af75b--