Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107729
Message-ID: <2336E1EC-6370-4D17-BC5D-427367E627EA@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D57F2169-E2B6-4875-8EB0-773362F94240"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 29 Oct 2019 17:56:25 -0400
In-Reply-To: <374ad5f6-be02-8762-c4c3-12cf34e70cad@gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: Rowan Tommins <rowan.collins@gmail.com>
References: <DC8C0F88-1B43-4601-A3D1-2EEA812B89B9@newclarity.net>
 <9d3f9895-5ab6-1d75-4eb2-0ba93f13a8fe@gmail.com>
 <9D2698F0-49A4-4EA0-BEEE-552D28BE995A@newclarity.net>
 <CALKiJKqCT2D4hmoLDBOTH9EHpZJeqDo-G7YXGutEY3uz647grg@mail.gmail.com>
 <C0F0F6B7-697E-4677-888E-8D8C569A01D6@newclarity.net>
 <374ad5f6-be02-8762-c4c3-12cf34e70cad@gmail.com>
Subject: Re: [PHP-DEV] Optional pre-compiler for PHP8?
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_D57F2169-E2B6-4875-8EB0-773362F94240
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Oct 29, 2019, at 5:49 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> I think the problem is that as soon as you have two engines targeting =
different feature sets, it will be hard to persuade people to spend =
equal attention on both. If all the new features end up being added to =
one engine, the other one is going to increasingly feel like "legacy =
mode", rather than "equal but different".

That is a fair point.

> It would be much better to keep it separate, and opt into it via a =
declare() statement, or a package configuration, or a file extension. =
There have been proposals for a single flag, lots of separate flags, a =
complete "P++" dialect, or bundles of settings ("Editions").

Correct me if I am wrong, but all of those have been objected to, =
strenuously, by at least several people on the list.

What will it take to finally get enough consensus to move forward?

> Both/all modes should get the same performance improvements, except =
where the actual features are necessarily slower or faster.

Fine. But a pre-compiler still could have merit.

One of the things I would like to see from a pre-compiler is getting rid =
of the need to deal with an autoloader and hence we able to store =
multiple related classes in the same file. =20

Primarily I would like this will doing R&D on a project idea prior to =
fully understanding what the object hierarchy needs to be. That, of =
course, would conflict with the non-pre-compiled code by its very =
nature.

-Mike




--Apple-Mail=_D57F2169-E2B6-4875-8EB0-773362F94240--