Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59700
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAORXhGLppTWU9nRfhWLwRtHK_ct4SSLJxpwqAM0g6cnNirPSHA@mail.gmail.com>
References: <CAORXhGK47pRN8uUTENqSbddQoCP8VopomPhJW7N2pN6ZU8vNPQ@mail.gmail.com>
	<CAKOpQSz5tdkHK=MVsC8+8oL+Q-TGDAP=uBBC=i0p0pSJ4mn38Q@mail.gmail.com>
	<CAORXhGLppTWU9nRfhWLwRtHK_ct4SSLJxpwqAM0g6cnNirPSHA@mail.gmail.com>
Date: Tue, 10 Apr 2012 19:10:56 -0700
Message-ID: <CAKOpQSzg5h539E341b5fyyUPj86Lf=E=r8B28PXrLcsj9O4RDw@mail.gmail.com>
To: Tom Boutell <tom@punkave.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d0442811ef5df7904bd5dbf96
Subject: Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening
 <?php tag
From: kris.craig@gmail.com (Kris Craig)

--f46d0442811ef5df7904bd5dbf96
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 10, 2012 at 6:50 PM, Tom Boutell <tom@punkave.com> wrote:

> On Tue, Apr 10, 2012 at 7:59 PM, Kris Craig <kris.craig@gmail.com> wrote:
> > Tom,
> >
> > Much better, though I'm still very troubled by allowing non-pure PHP
> code to
> > be mixed-in with pure PHP (by means of includes).  The problem I have
> with
> > this, as a developer, is that this means I can't really trust that what I
> > will get from a "pure PHP" script will actually be pure PHP, because
> > non-pure scripts lower in the stack might mix-in HTML code that would
> then
> > get passed up through the stack.  These really shouldn't be mixed
> anyway, so
> > I'm just not seeing any value in not keeping this separation consistent.
>
> The approach you suggest would make it impossible to load an existing
> library of perfectly good classes from a newer framework. I don't know
> anyone who would be able to get work done under those circumstances (:
> It would lead to almost no adoption of the new feature.
>

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.

If you're including a library that contains embedded HTML, you should do so
from a regular .php file.  Then you can include the .phpp file at that same
level, thereby avoiding the collision.

For example, here's what you're suggesting:

 -------------- (Main Script) ------------
|                                         |
|                                         |
[Included .php/HTML Script]     {Included .phpp Script}
                                          |
                                          |
                    [Included .php/HTML Script from Framework/Library]


That approach is bad architecture and simply unnecessary.  If you want to
interface with that library, do it like this instead:

                (Main Script)
                     |
                     |
         [Included .php/HTML Script]
             |                   |
             |                   |
{Included .phpp Script}      [Included .php/HTML Script from
Framework/Library]


In other words, instead of calling that third-party, HTML-containing
library from the .phpp file, call both it and the .phpp file from a regular
.php file, which will then act as the "controller" and bridge the
functionality between the two.  This would be a far more *sane* architecture,
anyway.  And it allows you to achieve the exact same result, without having
to have included HTML bits polluting the upstream from the pure PHP stack.

Make sense?  I'm just not seeing any value in breaking this model just so
that bad, lazy architecture that shouldn't be used in the first place can
be supported.


> Whereas if we make this feature easy to adopt, and strict within the
> files it does apply to, then over time we would see more and more
> .phpp and less and less .php. Mission accomplished. Sometimes a
> realistic compromise is the long term way to get to a better place.
>
> Think through what will likely happen in the real world under various
> proposals, and not just what would be most pure (:
>

See above.  =)


>
> --
> 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
>
>

--f46d0442811ef5df7904bd5dbf96--