Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106861
MIME-Version: 1.0
References: <CAF+90c_Ctjja=8fR-uBWL1wDxZge771yMujMhaR_R2seKXciYw@mail.gmail.com>
 <CAOWwgpmsHMjnHuH4tfv_5-0f+pGKv2jJmA5v21FbkdpSHTbTJQ@mail.gmail.com>
 <25d774e8-183b-d39c-4ac4-81c1b7770229@gmail.com> <5d5298a5.1c69fb81.b4ed1.2d97SMTPIN_ADDED_MISSING@mx.google.com>
 <3db68c5e-54d1-812f-bbf5-1b089cba1bff@gmail.com> <5d52f72d.1c69fb81.8f95f.57a1SMTPIN_ADDED_MISSING@mx.google.com>
 <2bcb05d6-abf6-4fcb-599e-eaf4bcd58878@gmail.com> <CABdc3Wp+HWtbvab78T47sDuGQbBKkUagk-AL0qS4TO97AaoD6g@mail.gmail.com>
 <182a6bd5-4057-7ba1-2cca-ab0be37e0b75@gmail.com> <CABdc3WoJzZGoxcLUzHoam=r+4bs7ED9j4+Oz+=+Jk+d_0S2yXA@mail.gmail.com>
 <72896017-20d0-16af-b188-8500777f947b@gmail.com> <CABdc3Wo=9V7=pOSXqBEwfW6+9ZGcMAngnKzgRVvqgiCXBX3AZA@mail.gmail.com>
 <00eea416-23be-6629-2e94-4cfa9f5fcb39@gmail.com> <CABdc3Wo9nnwG_Nj8jDUV+X16L1JaEjrmkvsewD7eM60j3Z9vOg@mail.gmail.com>
 <CABdc3WrU=T6hEsBrR+hec-_Hxkr5TXT01p-MXKVWrXtD=qsvmg@mail.gmail.com>
In-Reply-To: <CABdc3WrU=T6hEsBrR+hec-_Hxkr5TXT01p-MXKVWrXtD=qsvmg@mail.gmail.com>
Date: Thu, 5 Sep 2019 00:16:05 +0200
Message-ID: <CAH0Uv3GnnNW13eZq-LXJmKqKGCRff0x_WbiJ9g1KN82pGzN7zQ@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal@brzuchalski.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
From: andreas@dqxtech.net (Andreas Hennings)

I would like to make a wild proposal.

## Proposal

Similar to spl_autoload_register(), we would provide a function that
allows to register a callback to provide the declares / edition /
compatibility information for a given file, before this file is
loaded.

To address performance concerns:
- The result of the callback is cached per file, and per "application
cache key". (*)
- The callback has the option to additionally provide compatibility
information for an entire directory, or a path pattern.

Callback signature:
- The primary parameter is the absolute path of the file, after
symlinks are resolved.
- Additional parameters could provide the version of the path that was
passed to include / require.
- An additional parameter could provide the class name, if we are
currently doing autoload lookup (ouch, this could be complicated).
- An additional parameter could contain the namespace. This would
require that the parsing already begins, before the compatibility
information is available.
- An additional parameter could contain class names and function names
declared in the file. This would imply that the file is already parsed
before the compatibility information is available.

(*) Caching mechanism:
- Different PHP "applications" can have different cache keys, so that
they do not poison each other. This could be provided in the initial
function call along with the callback.
- If no cache key is provided, the starting script path is used (e.g.
/path/to/index.php)
- There needs to be a function to clear this cache for the current applicat=
ion.
- The opcache could contain different versions of a file for different
compatibility levels.

Combination with other proposals:
There could still be functions to set compatibility information for an
entire directory or namespace preemptively.
There could also be ways to disable this special file-by-file callback
for specific directories or namespaces.


## Motivation

We saw proposals where the "edition" or "declares" would be on file
level, on namespace level, on directory level, or on package level.
The basic idea (mostly) was that the author provides compatibility
information which is then picked up by PHP.
The author of a package should be responsible for this, and it should
be protected from side effects from other packages.
Any file or package should have one definitive compatibility info,
which should not be changed from outside.

The proposal turns this on its head.
It is now the responsibility of the package manager (e.g. Composer) or
the framework to organize different compatibility levels in the
application.

Once some conventions have been established by the community (e.g.
Composer), the IDE can extract information from e.g. composer.json to
apply the appropriate checks on each file.

Benefits:
- Fine-grained control where needed, e.g. override the directory-level
or namespace-level compatibility information for specific files.
- Keep boilerplate out of the file header. No need to update all files
when a new compatibility type / edition is released.
- No verbose and noisy git commits in the package history.
- Option for shared compatibility information across "packages", e.g.
for the entire application.
- No need for an artificial "package" concept on language level. Let
community tools (e.g. Composer) define what a package is.
- Possibility to test-run an application or specific files with
different compatibility level.
- Possibility to control compatibility level based on dynamic file
lists, which can be updated based on error statistics, or which can be
updated file by file to slowly make an existing codebase compliant
with a new version.
- The average developer only needs to learn the API of the framework
or package manager, and does not need to deal with this on language
level.

Flaws:
- No explicit compatibility information when looking at a specific file.


## Assumptions

It is a assumed that "compatibility level" does NOT change the meaning of c=
ode.
When running a file with a different compatibility level than it was
designed for, we may get errors and warnings, but we do not want to
get silent changes in behavior.


Now I want to see this idea being barbecued..

On Wed, 14 Aug 2019 at 12:27, Micha=C5=82 Brzuchalski <michal@brzuchalski.c=
om> wrote:
>
> =C5=9Br., 14 sie 2019 o 12:17 Micha=C5=82 Brzuchalski <michal@brzuchalski=
.com>
> napisa=C5=82(a):
>
> >
> >
> > =C5=9Br., 14 sie 2019 o 12:11 Rowan Collins <rowan.collins@gmail.com>
> > napisa=C5=82(a):
> >
> >> On 14/08/2019 11:07, Micha=C5=82 Brzuchalski wrote:
> >> > Exactly so how would it know from string name either it should load
> >> class
> >> > from src/Foo.php or src/__nsmeta.php if there is no information?
> >>
> >>
> >> It wouldn't. It would include src/Foo.php, and that would have the
> >> definition of something with the name "Foo" - either a class, an
> >> interface, a trait, or a package. If it wasn't what the engine was
> >> expecting, it would be an error, just as it is right now if you write
> >> "implements ClassName", or "new TraitName();"
> >>
> >
> > Following that would introduce unneeded additional directory hierarchy
> > level in a usual library
> > which uses PSR-4 which is the most used one, right?
> >
> > /composer.json
> > /src/Foo.php
> > /src/Foo/ <- all package classes should go here?
> >
>
> Going even further by the example of Doctrine libraries:
> # doctrine/collections - Composer Package [1]
> uses PSR-4 autoload with "Doctrine\\Common\\Collections\\" prefix
> to adopt package concept it would have to change the prefix to
> "Doctrine\\Common\\"
> to find Collections.php and all the rest of source code in Collections
> directory
>
> # doctrine/common - Composer Package [2]
> uses "Doctrine\\Common\\" prefix should change into "Doctrine\\" to be ab=
le
> to load
> Common.php and the rest of source code in Common directory
>
> # ocramius/package-versions - Composer Package [3]
> uses "PackageVersions\\" prefix and then what?
>
> [1] https://github.com/doctrine/collections/blob/master/composer.json
> [2] https://github.com/doctrine/common/blob/master/composer.json
> [3] https://github.com/Ocramius/PackageVersions/blob/master/composer.json
> --
> regards / pozdrawiam,
> --
> Micha=C5=82 Brzuchalski
> about.me/brzuchal
> brzuchalski.com