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.
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
>
>
