Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59969
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKOpQSx5Kva1m3wHC7rUkp36avmcbfbBWXgwWx7_t1Pkgk8i1g@mail.gmail.com>
References: <CAKOpQSwYe+tZ3JfLFWaOHCnBpUyy9yoA61=qLzbnnOKTL0mQdQ@mail.gmail.com>
	<CAGa2bXa554p45tbNFvtHQJiYTXaa0eD6r+qnExDVk+6e8PRvMw@mail.gmail.com>
	<4F876943.8030105@gmail.com>
	<CAKOpQSzAZauE9HYK3x-5UbxAstkdkc-HkfZRa+E+i=DNxQwkBA@mail.gmail.com>
	<4F877777.8050806@gmail.com>
	<CAKOpQSyC6Zs=3-AQ8=L-aufTP03j0yhnRiu3n6pNP7YSpW_KLg@mail.gmail.com>
	<4F8782CC.8030205@gmail.com>
	<CAKOpQSzKo9ZX1voYppTRihkfkpfCywMLLv_DF8XWGxcOV1Su8Q@mail.gmail.com>
	<CAGsnKxaR8vHHeZrpDhf4WVBKqDwMXrAf=b=3r06oJZpP4K3sPg@mail.gmail.com>
	<CAKOpQSyVu3ddZubCeo4BpZTWFXf55_yYNbrhDqTJkDjPoX6xVw@mail.gmail.com>
	<CAGsnKxatwB-T5ExGjq9z0FyjhRB0DKVRigu=opqXbjoyUAcwRA@mail.gmail.com>
	<CAKOpQSy3BVpY-UNSvVkQSoPBV=ZKdiJ0nOC14ou3YRdJM5XmnQ@mail.gmail.com>
	<4F87C9B0.4080809@gmail.com>
	<CAKOpQSz-hMYHpcrs_f5vKmZTKvvAckJwNswsK33xqJ49fN3=6A@mail.gmail.com>
	<4F8AA9CF.6000003@gmail.com>
	<CAKOpQSx5Kva1m3wHC7rUkp36avmcbfbBWXgwWx7_t1Pkgk8i1g@mail.gmail.com>
Date: Sun, 15 Apr 2012 23:21:54 +0200
Message-ID: <CAH-PCH4RTbxqZe2f=pAo1zCLO4gK4frjN-fAixnhJXUKVx0JPg@mail.gmail.com>
To: Kris Craig <kris.craig@gmail.com>
Cc: David Muir <davidkmuir@gmail.com>, John LeSueur <john.lesueur@gmail.com>, 
	internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7b15afe1737dba04bdbe4ba7
Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b15afe1737dba04bdbe4ba7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
>
> The gain has been described by myself and others quite a bit already.  As
> far as I can tell, the fact that some frameworks/libraries wouldn't be
> compatible with this doesn't negate the unrelated advantages that do exis=
t.
>  Worst-case scenario, you just wouldn't use this with those frameworks.
>

usually we tend to accept changes only if the pros remarkably overweight
the cons.
introducing a new language construct which target audience is just a small
percentage of the potential userbase seems to have a hard time getting
accepted.
(annotations was an example of this, even thought that the syntax was
thought out, and it was/is already used in the wild (Doctrine2, Symfony2)
the majority of the voters seemed to be against it)

of course you can succeed where others failed, but I think it would greatly
increase the chances if:
1, the intention of the change is clearly laid out, and easily understood
via reading the RFC
2, the change would make some useful real-life scenario possible or
significantly easier
3, the change would make the least impact on the pre-existing code(minimal
required BC impact)
4, the change is in line with the "PHP way".

I think that the current proposals are lacking in those aspects.


but to go back to your proposal:
I think that it would be nice, if you could update the RFC based on the
discussion, as it will be harder and harder to join the discussion, if one
has to read the RFC then read all of the related discussion (scattered
through many threads) in the correct order to be able to catch up with the
current status.
you mentioned that some ideas or alternatives was presented but you didn't
wanted to incorporate those, until you finish sorting those out in the
mailing list and consensus is reached.
which is a good idea at first, but if/when the discussion is
abadoned/derailed/etc. then there it is a good chance, that the original
idea is lost too.
I really liked the https://wiki.php.net/rfc/closures/object-extension in
this regard (even though that in the end that was also abandoned so it
isn't consistent with the actual implementation).
It describes the ideas which were presented, compares the pros/cons, etc. I
really liked that.
So I would suggest you to update you RFC accordingly (and while I think
that the separate nophptags RFCs should be kept separate, but mentioning
what deviates yours from the other two could be a good idea too).

"Over the years, people have occasionally called for one of a few
fundamental changes"
would be nice if you could link those calls if you have them, maybe they
have some arguments that we didn't see yet (or maybe we could see that some
of those are PEBKAC)

"There will be no BC breaks."
depending on the implementation (making the SAPIs aware of the new file
extension or the parser to the new <?phpsomething tag) there is a small
chance that somebody already using that extension/tag which would turn
those files executable php scripts. ofc. it isn't that likely.

of course if we go with the <?phpsomething tag, then the many of the
current premises needs to be rewritten, and it would remove the "I can save
5 keystrokes per files" and "some random output by mistake before the
opening tag sending out junk before the opening tag" from the equitation.
you still need to have an opening tag, and you can also put something
before the tag (albeit I think that those problems would error out with
<?phpo either because the <?phpo could be only at the begining of the file,
or by an unexpected direct output in case of another phpp file including
the borked file),
so what we have left is the ability to create an arbitrary restriction so
that phpp files cannot switch to "template" mode or include files(directly
or indirectly) which would do that.

As others (and your RFC) stated, this would only cover part of the original
issue: class files spitting out direct input.
Your solution would only solve half of the problem, but in exchange you
would make the promise that under no circumstances would you try to include
any php file from your phpp file.
Which can be a really hard thing to promise upfront:
- if you have file includes based on some dynamic logic(the filename coming
from database for example).
- if you have a global autoloader, that can cause hard-to-see dependencies.
- if you have an error/exception handler, that can cause hard-to-see
dependencies.

I think it would make more sense, if we would solve the original problem:
preventing the the class files from spitting out output.
one could do something similar via ob_start-ing before the file include and
discarding the buffer or erroring out if the buffer isn't empy (albeit that
would only prevent the mistakes, not the malicious code from flushing the
buffer).
another possibility would be adding control options for the include/require
calls, so one can tell whether the included files can have output (or
allowing a variable to be passed, which will hold the generated output,
that would be really nice, as many of the php template engines have to do
ob magic already to be able to return the template output instead of
outputting it.)

ps: sorry for the wallpost, and being a little bit disorganised.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7b15afe1737dba04bdbe4ba7--