Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59516 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23488 invoked from network); 9 Apr 2012 16:44:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Apr 2012 16:44:23 -0000 Authentication-Results: pb1.pair.com smtp.mail=johncrenshaw@priacta.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=johncrenshaw@priacta.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain priacta.com designates 64.95.72.241 as permitted sender) X-PHP-List-Original-Sender: johncrenshaw@priacta.com X-Host-Fingerprint: 64.95.72.241 mxout.myoutlookonline.com Received: from [64.95.72.241] ([64.95.72.241:35798] helo=mxout.myoutlookonline.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CD/E1-14133-6E1138F4 for ; Mon, 09 Apr 2012 12:44:23 -0400 Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D1485553861; Mon, 9 Apr 2012 12:44:19 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A3C7D55480A; Mon, 9 Apr 2012 12:43:45 -0400 (EDT) Received: from MAILR001.mail.lan ([10.110.18.28]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Mon, 9 Apr 2012 12:43:45 -0400 To: Tom Boutell , PHP Internals Date: Mon, 9 Apr 2012 12:43:37 -0400 Thread-Topic: [PHP-DEV] PHP class files without References: <4F80C739.2060404@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [PHP-DEV] PHP class files without John, please take a look at the RFC: > > https://wiki.php.net/rfc/source_files_without_opening_tag > > I am not proposing any backwards-incompatible changes that would affect e= xisting code. Code that isn't interested need not ever take advantage of th= e feature and can interoperate with code that does. I realize there is conf= usion about this because of a separate and unrelated RFC to actually elimin= ate > I agree that the security argument is bogus, but it was never one of my r= easons for this proposal. > Yeah, the discussion isn't always focused. I was responding to some argumen= ts that are mostly separate from what is specifically proposed in your RFC. About the RFC: 1. Passing two parameters to a keyword feels super awkward. I think it's fa= ir to require this to be used more like a function. 2. IMO the selected name (require_path) is confusing. There are still some ecosystem issues, and interoperability is somewhat red= uced in the sense that all 3rd party code would have to be checked for the =