Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95665 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 20397 invoked from network); 5 Sep 2016 18:19:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Sep 2016 18:19:22 -0000 X-Host-Fingerprint: 90.212.141.121 unknown Received: from [90.212.141.121] ([90.212.141.121:12924] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CF/96-45301-727BDC75 for ; Mon, 05 Sep 2016 14:19:20 -0400 Message-ID: To: internals@lists.php.net References: Date: Mon, 5 Sep 2016 19:19:13 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 90.212.141.121 Subject: Re: [PREVOTE] PHP Engine Constants From: ajf@ajf.me (Andrea Faulds) Hi Davey, Davey Shafik wrote: > A while back I brought a small RFC to internals, that proposed a set of > constants that were specifically for alternative implementations to > identify themselves as such if they want to conform to the spec. > > https://wiki.php.net/rfc/php_engine_constant > > There were some folks who didn't like it, but nobody suggested different > implementations, just didn't feel it was necessary. As such, I'm planning to > bring it to a vote next week - this is simply a heads up as it's been a > while > and I want to give a chance for any objections other than not wanting it to > be voiced before I open it up for voting. This is an interesting idea. Have you asked the HHVM team what they think about it? Their input is probably more important than ours, as the foremost alternative implementation. The implications of it are interesting. Currently, PHP doesn't really have any separation between the current version of the PHP interpreter and the version of the language. Despite the specification efforts, PHP versions are effectively defined by the main implementation. Would this RFC be changing that, decoupling the version of PHP, the language, from PHP, the interpreter? Would we no longer report the version of PHP as, say, “7.1.1”, but instead as just “7.1”, and put “7.1.1” as the engine version? The micro version, at least with the modern release process, is only meaningful for the PHP interpreter, and not other implementations. Also, isn't there a danger of code sniffing for the engine? I wouldn't be entirely surprised if, in future, HHVM might start pretending to be PHP by default. Anyway, that's just a few thoughts of mine. -- Andrea Faulds https://ajf.me/