Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107722
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 10:00:50 +0000
Message-ID: <CALKiJKqCT2D4hmoLDBOTH9EHpZJeqDo-G7YXGutEY3uz647grg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bf55620595f593ee"
Subject: Re: [PHP-DEV] Optional pre-compiler for PHP8?
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000bf55620595f593ee
Content-Type: text/plain; charset="UTF-8"

On Sun, 27 Oct 2019 at 23:56, Mike Schinkel <mike@newclarity.net> wrote:

>
> 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.
>
> But then again a new package concept might be needed in addition to
> namespaces, I am not certain either way.
>
>


Current tools tend to actually work on a directory level, because you don't
actually know what namespaces are involved until after you've loaded it,
and a file can include code for two completely separate namespaces. My
thinking was that a package would pre-define the full list of files that
define it, with no auto-loader, and no conditional definitions evaluated at
run-time. As Benjamin points out, this is closely related to preloading.




> 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 for
> building large applications, then the "right way" would still be the
> "unstrict way."
>
>


And what if you want simplicity *and* performance? Most of the things
people want to make strict about the language don't make it faster, so if
we limited "pre-compiled mode" to be strict, we'd be making a deliberate
choice to group objectively good things (fast vs slow) with subjective
preferences (strict vs simple). That pretty clearly marks strict mode as
"the better 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.
>
>


That sounds like the worst kind of fork: two different engines, running two
different dialects of the language. At that point, you might as well just
switch to Hack.

Note that this was exactly what "P++" was intended to avoid - the two
dialects would exist in the same engine, and get the same performance and
security enhancements.




> 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.
>
>


Both of these are reasons to have some sort of "strict mode", but not for
tying it to some other feature.


Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000bf55620595f593ee--