Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59496
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.216.49 as permitted sender)
References: <CAORXhGJwmbjw3Zze3+-oFA2Mb_Z-2owVESraNMMs57RzjRRMbA@mail.gmail.com> <CAGa2bXbjiNMv0g6BBZkuTtUe66gz-p8mQxRk+_0fisiJUADRgQ@mail.gmail.com> <CAGa2bXYhS9QCWarTKyBgv3Vnh8D8S=+Vic-XQZm0w6dqrkpf6A@mail.gmail.com> <CAORXhG+y0P+dM9x1_uewp0sXpHoz_4WDbjAUoRf4Auxv6FcUUQ@mail.gmail.com> <CAGa2bXZUUqVaKmv7wyjUtXzD9VN=HjEwpFVOEmAHpo9QPePwWQ@mail.gmail.com> <CAORXhGJ+ptX=ER6=u1G0OKYqF=PJ=FX-qd9KR8=M2VKK5oBtGg@mail.gmail.com> <CAKOpQSyV+yeaTpr_dXwktckv4W3NszMRxe3czD_SkGgnG57WMg@mail.gmail.com>
In-Reply-To: <CAKOpQSyV+yeaTpr_dXwktckv4W3NszMRxe3czD_SkGgnG57WMg@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative;
	boundary=Apple-Mail-999C2144-17CE-4CB7-86F5-FC9690142C20
Message-ID: <429575FE-15D6-4AD4-84A3-B8BF6B4FBB3B@punkave.com>
Cc: PHP Internals <internals@lists.php.net>
Date: Mon, 9 Apr 2012 06:55:39 -0400
To: Kris Craig <kris.craig@gmail.com>
Subject: Re: [PHP-DEV] RFC: source files without opening tag
From: tom@punkave.com (Tom Boutell)

--Apple-Mail-999C2144-17CE-4CB7-86F5-FC9690142C20
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

.phpp would be fine.

.phpp code needs to be able to interoperate with .php templates, otherwise o=
ne can't supply reusable libraries that implement generic algorithms without=
 surprises for those who integrate them in older projects.

Sent from my iPhone

On Apr 9, 2012, at 1:16 AM, Kris Craig <kris.craig@gmail.com> wrote:

> Tom,
>=20
> On Sun, Apr 8, 2012 at 4:14 PM, Tom Boutell <tom@punkave.com> wrote:
> Thanks. However, would you please fix the summary on the RFC's page to
> match the summary in the actual RFC? As you have written it, it
> implies that support for <?php would be completely removed. This is
> not the case.
>=20
> As for adding a boolean parameter to the require keyword, as the RFC
> mentions there are already at least two distinctions already when
> requiring files in PHP:
>=20
> * include vs. require behavior (warning vs. error on failure)
> * once vs. every time (require_once vs. require)
>=20
> And we are proposing a third:
>=20
> * start in php mode vs. start in html mode
>=20
> We already have four keywords for requiring files. At this point it
> does not make sense to keep introducing more keywords (we would need 8
> with this change). Your boolean flag proposal keeps it to four
> keywords, but as soon as someone adds another flag it will become
> awkward to remember them. Since PHP does not have named parameters I
> think an associative array is the best way to go (especially with the
> new short syntax).
>=20
> Also I don't think it makes sense to forbid shifting into html mode
> later in the file, it could reduce support for the proposal needlessly
> - since it already lets people who want to write clean all-PHP files
> do so, and some of those people might have legitimate reasons to use
> HTML mode in the scope of a function or method (where it does not
> suddenly introduce whitespace without being explicitly called, etc).
>=20
> But if it really came down to it I could live with an "absolutely
> nothing but PHP" behavior when the code flag is true (supporting <?php
> when the flag is not set is a must of course).
>=20
> On Sun, Apr 8, 2012 at 6:45 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> > Hi,
> >
> > I talked on twitter.
> > Yes, he is kidding, but he is serious, too.
> >
> > I've added the RFC to Under Discussion and added
> > security issue description. I also added my proposal that
> > controls embed mode.
> >
> > BTW, I don't think we need new "require_path" why don't
> > we use
> >
> > require "file.php", ture;
> >
> > or some thing similar?
> > I prefer to use switch, since security countermeasure is
> > better to be enforced by switch.
> >
> > Regards,
> >
> > --
> > Yasuo Ohgaki
> > yohgaki@ohgaki.net
> >
> >
> >
> > 2012/4/9 Tom Boutell <tom@punkave.com>:
> >> Moriyoshi was kidding, as near as I can tell (:
> >>
> >> To take it at face value though, the *cough* April 1st *cough*
> >> proposal of Moriyoshi calls for the complete abolition of the feature
> >> with no backwards compatibility with existing code that uses PHP as a
> >> template language... including most popular frameworks that sensibly
> >> obey a separation between class files and template files but still use
> >> PHP rather than a dedicated templating language for templates.
> >>
> >> I don't think that's realistic (and neither did the author it
> >> appears). Since PHP's usability as a template language may conceivably
> >> be improved by other proposals, it is undesirable as well even if you
> >> don't currently find PHP to be a suitable template language.
> >>
> >> Please read my proposal over carefully as it does address the obvious
> >> issues that make Moriyoshi's proposal possibly less than serious in
> >> intent (:
> >>
> >> I would oppose a php.ini flag for this as that gives us two
> >> incompatible versions of the current version of the language to worry
> >> about and makes the feature effectively unusable in reusable code.
> >> This approach has created problems before.
> >>
> >> On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote=
:
> >>> Hi,
> >>>
> >>> There is RFC that is written by Moriyoshi.
> >>> It's not listed in RFC page, though.
> >>>
> >>> https://wiki.php.net/rfc/nophptags
> >>>
> >>> I think these should be merged.
> >>>
> >>> Regards,
> >>>
> >>> --
> >>> Yasuo Ohgaki
> >>> yohgaki@ohgaki.net
> >>>
> >>>
> >>>
> >>> 2012/4/9 Yasuo Ohgaki <yohgaki@ohgaki.net>:
> >>>> Hi,
> >>>>
> >>>> Moriyoshi has created same entry on 4/1, but
> >>>> it seems it was deleted  already.
> >>>>
> >>>> Anyway, he had a patch for it.
> >>>>
> >>>> https://gist.github.com/2266652
> >>>>
> >>>> As I mentioned in other thread, we should better to have
> >>>> a switch to disable embed mode for security reasons.
> >>>>
> >>>> Regards,
> >>>>
> >>>> --
> >>>> Yasuo Ohgaki
> >>>> yohgaki@ohgaki.net
> >>>>
> >>>>
> >>>>
> >>>> 2012/4/9 Tom Boutell <tom@punkave.com>:
> >>>>> I have written an RFC proposing backwards-compatible support for
> >>>>> source files without an opening <?php tag:
> >>>>>
> >>>>> https://wiki.php.net/rfc/source_files_without_opening_tag
> >>>>>
> >>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sur=
e
> >>>>> what the requirements are to get it added to the "Under Discussion"
> >>>>> session and get the ball rolling formally. Please enlighten and I'll=

> >>>>> do whatever is required.
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> --
> >>>>> 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
> >>>>>
> >>
> >>
> >>
> >> --
> >> 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
> >>
>=20
>=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
> I think this is a great idea overall, but it seems to me as though we're n=
eedlessly over-complicating things.  If we just go with a separate file exte=
nsion for pure PHP code (i.e. everything in the file is parsed as if it was c=
ontained in a <?php tag and the ?> tag would throw an error), then there's n=
o need for adding new keywords or INI flags.  If a pure PHP file includes a r=
egular PHP file that contains HTML, a warning would be thrown and anything n=
ot within the <?php tag of the included file would be ignored.  Everybody's h=
appy.  No BC breaks.  No additional flags/keywords to muddle around with.
>=20
> That said, we might want to consider a file extension other than ".phpc". =
 There are some PHP-related projects/commits that already use this file exte=
nsion for other purposes and could be broken by this.  Probably wouldn't be a=
 huge deal but a quick Google search shows that we would be stepping on a fe=
w people's toes by going with that extension.
>=20
> Instead, how about going with ".phpp" (as-in, "PHP Pure")?  A Google searc=
h on that shows it's not being used anywhere (except for one blog post from 2=
007 that linked to a .phpp file, but it looks like he just named it that so t=
hat it wouldn't be parsed by the webserver).  That way we wouldn't be creati=
ng any conflicts with existing applications/projects.  =3D)
>=20
> --Kris
>=20

--Apple-Mail-999C2144-17CE-4CB7-86F5-FC9690142C20--