On Wed, Apr 11, 2012 at 5:07 AM, Tom Boutell <t...@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.cr...@gmail.com> wrote:
>
> >
> >
> > On Tue, Apr 10, 2012 at 8:35 PM, Tom Boutell <t...@punkave.com> wrote:
> > On Tue, Apr 10, 2012 at 10:10 PM, Kris Craig <kris.cr...@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
> >
> >
>
