Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107711
Message-ID: <9D2698F0-49A4-4EA0-BEEE-552D28BE995A@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_65727FAB-43AF-4FC5-A4C0-89CD555AE727"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 27 Oct 2019 19:56:37 -0400
In-Reply-To: <9d3f9895-5ab6-1d75-4eb2-0ba93f13a8fe@gmail.com>
Cc: 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>
Subject: Re: [PHP-DEV] Optional pre-compiler for PHP8?
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_65727FAB-43AF-4FC5-A4C0-89CD555AE727
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Oct 27, 2019, at 7:04 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:

Thank you for your comments.

> I chose the phrase "static analysis tool" deliberately, because I =
wanted to think about the minimum requirements for such a tool, rather =
than its long-term possibilities.

Your points are all well-considered.

To be clear, I wasn't stating the idea as a alternative to your idea, I =
was only stating that your comments inspired me to have the idea of a =
pre-compiler. =20

IOW, I saw no reason both could not be done, one sooner and the other =
later.

> However, combining those usefully may not be that easy.

Also for clarity, I was not assuming existing OpCache would be 100% =
unmodified, I was talking about benefits that a pre-compiler could have =
and was less focused on ensuring it could slot into an existing OpCache =
implementation as-is.

IOW, if it is worth doing it might be worth extending how the OpCache =
works.

> So we'd probably need some built-in definition of a "package", which =
could be analysed and compiled as one unit, and didn't rely on any =
run-time loading.

That idea of a "package" came up during a debate on this list at least =
once, a few months ago, and I think it makes a lot of sense. And what I =
proposed effectively implies that namespaces would be treated like =
packages from the perspective of the compiler.=20

But then again a new package concept might be needed in addition to =
namespaces, I am not certain either way.

> Unlike P++, Editions, or Strict Mode, this would undeniably define =
that the deprecated features were "the wrong way".

I am not sure I cam agree that it would define them as the "wrong way." =20=


The way I would see it is there would be a "strict way" and an "unstrict =
way."  If you prefer the simplicity of low strictness and do not need =
more/better performance or the benefits of type-safety that are needed =
for building large applications, then the "right way" would still be the =
"unstrict way."=20

And the non-strict features would not be "deprecated" per-se, they would =
instead be disallowed for the strict (compiled) way, but still allowed =
for the unstrict (interpreted) way.

> If the engine had to support the feature anyway,

I think we are talking two engines; one for compiling and another for =
interpreting.  They could probably share a lot of code, but I would =
think it would still need to be two different engines.

> I'm not sure what the advantage would be of tying it to "compiled vs =
non-compiled", rather than opting in via a declare() statement or =
package config.

The advantage would be two-fold:=20

1. Backward compatibility

2. Allowing PHP to continue to meet the needs of new/less-skilled =
programmers and/or people who want a more productive language for =
smaller projects that do not need or want all the enterprisey type-safe =
features.

Frankly it is this advantage which is the primary reason I though to =
send a message to the list. The chance to have the benefit of strictness =
and high performance for more advanced PHP developers while still having =
full BC for existing code and for beginner developers seemed highly =
compelling to me.

-Mike


--Apple-Mail=_65727FAB-43AF-4FC5-A4C0-89CD555AE727--