Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107726
Message-ID: <C0F0F6B7-697E-4677-888E-8D8C569A01D6@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_CF71E31A-017C-4CF3-A482-0CA54DAF6A47"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 29 Oct 2019 15:04:12 -0400
In-Reply-To: <CALKiJKqCT2D4hmoLDBOTH9EHpZJeqDo-G7YXGutEY3uz647grg@mail.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>
Subject: Re: [PHP-DEV] Optional pre-compiler for PHP8?
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_CF71E31A-017C-4CF3-A482-0CA54DAF6A47
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Oct 28, 2019, at 6:00 AM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> 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.

I would rather a tool that did not require specifying the files. I =
personally would be fine with one that used a directory as the =
demarcator, and even if it only worked when you put your namespace in =
another directory it won't work.

> 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".

At the risk of being too flippant, I defer to the wisdom on that great =
philosopher Mick Jagger and say you can't always get what you want...

But seriously, at some point tradeoffs have to be made to see any =
forward progress.  What we have not found before was a good tradeoff =
between strict and BC. Maybe this it is? After all, while not all strict =
things are about performance but many things that enable performance are =
strict.


> 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.

That feels like an over-reaction.  Hack has purposely diverged from PHP =
and requires a different runtime than PHP. =20

The idea I was proposing is that the PHP runtime be one but operates in =
two different modes =E2=80=94 one mode per "engine" =E2=80=94 and the =
goal of two different modes would to be to stay more similar than =
different, but allow one of them to have BC breaks.

> 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.

It could also be one engine, it just seemed like that coupling would be =
more problematic than separating them.

That said, I'm not skilled enough in PHP internals to implement it =
(yet?) so I can only speak to it at a high level.

>> The advantage would be two-fold:
>>=20
>> 1. Backward compatibility
>>=20
>> 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.
>=20
> Both of these are reasons to have some sort of "strict mode", but not =
for
> tying it to some other feature.

I don't understand your reply, but maybe it is moot considering the rest =
of the dialog?

What we have today is a rock vs a hard-place, and no one wants to give =
even a millimeter.

So, if this is not a viable solution in your mind to break the logjam =
between BC and the desire for strictness-in-all-the-things, do you have =
an alternate, better proposal?

-Mike


--Apple-Mail=_CF71E31A-017C-4CF3-A482-0CA54DAF6A47--