Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107712
MIME-Version: 1.0
References: <DC8C0F88-1B43-4601-A3D1-2EEA812B89B9@newclarity.net>
 <9d3f9895-5ab6-1d75-4eb2-0ba93f13a8fe@gmail.com> <9D2698F0-49A4-4EA0-BEEE-552D28BE995A@newclarity.net>
In-Reply-To: <9D2698F0-49A4-4EA0-BEEE-552D28BE995A@newclarity.net>
Date: Mon, 28 Oct 2019 01:32:43 +0100
Message-ID: <CAG9XoMSeOaBTf=P4WaaVFZGFoXZJeyTKuH4agniy9Jw6U5EHag@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: Rowan Tommins <rowan.collins@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fb47b90595eda3b0"
Subject: Re: [PHP-DEV] Optional pre-compiler for PHP8?
From: benjamin.morel@gmail.com (Benjamin Morel)

--000000000000fb47b90595eda3b0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> > 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-ti=
me
> 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 packag=
es
> from the perspective of the compiler.



Putting aside the idea of distributing pre-compiled PHP scripts, if we're
only debating the precompilation as, notably, a means to reduce the cost of
type checks, I wouldn't mind if the precompilation occurred *only if
preloading is in use*, i.e if most class definitions are known on server
startup, which is when the compilation / optimization passes could occur.
No preloading =3D no such optimizations, I could personally live with that.

No need for a package definition, IMO.

=E2=80=94 Benjamin

On Mon, 28 Oct 2019 at 00:56, Mike Schinkel <mike@newclarity.net> wrote:

> > 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 wante=
d
> 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.
>
> 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 a=
nd
> 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-ti=
me
> 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 packag=
es
> from the perspective of the compiler.
>
> 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."
>
> 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 fo=
r
> building large applications, then the "right way" would still be the
> "unstrict way."
>
> And the non-strict features would not be "deprecated" per-se, they would
> instead be disallowed for the strict (compiled) way, but still allowed fo=
r
> 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:
>
> 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
>
>

--000000000000fb47b90595eda3b0--