Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106551
MIME-Version: 1.0
References: <CAF+90c_Ctjja=8fR-uBWL1wDxZge771yMujMhaR_R2seKXciYw@mail.gmail.com>
 <CAOWwgpmsHMjnHuH4tfv_5-0f+pGKv2jJmA5v21FbkdpSHTbTJQ@mail.gmail.com>
In-Reply-To: <CAOWwgpmsHMjnHuH4tfv_5-0f+pGKv2jJmA5v21FbkdpSHTbTJQ@mail.gmail.com>
Date: Mon, 12 Aug 2019 10:26:37 +0200
Message-ID: <CAF+90c_R6j0R5jJ5N2VmOSKb_gij6WMH=8h1Qjz+sBUMX11MSA@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000053bdb4058fe7491c"
Subject: Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000053bdb4058fe7491c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 12, 2019 at 10:17 AM Nicolas Grekas <
nicolas.grekas+php@gmail.com> wrote:

> Le lun. 11 d=C3=A9c. 2017 =C3=A0 14:44, Nikita Popov <nikita.ppv@gmail.co=
m> a
> =C3=A9crit :
>
>> Some time ago I introduced the following proposal for namespace-scoped
>> declares:
>>
>>     https://wiki.php.net/rfc/namespace_scoped_declares
>>
>> The idea is to allow specifying declare directives for a whole library o=
r
>> project using:
>>
>>     namespace_declare('Vendor\Lib', ['strict_types' =3D> 1]);
>>
>> I've finally gotten around to implementing this proposal (
>> https://github.com/php/php-src/pull/2972) and would like to move forward
>> with it.
>>
>> The reason why I'm picking it up again is some feedback I received for t=
he
>> explicit call-time send-by-ref proposal. The main objection seems to be
>> that the feature has limited usefulness if it's optional rather than
>> required, because you still can't be sure that something is a by-value
>> pass, just because no & is present. At the same time, we can't make this
>> required anytime soon due to the large BC impact.
>>
>> Namespace-scoped declares are perfectly suited to resolve this problem. =
We
>> can introduce a require_explicit_send_by_ref declare directive to make t=
he
>> call-site annotation required, and libraries/projects can easily opt-in =
to
>> it using namespace_declare(). There would be no BC impact, while at the
>> same time projects could benefit from the additional clarity and
>> performance improvements immediately.
>>
>
> I've read discussions about the notion of a "package" and the way we
> should define its boundaries.
> What about the following?
>
> Individual files could declare their package using this style:
> <?php declare(package=3DMyVendor\MyPackage);
>
> That would be enough to group a set of files together and make them share
> eg some private classes, some optional PHP behaviors, etc.
>
> The right side "MyVendor\MyPackage" would also be a FQCN that PHP would
> autoload as a regular class. The corresponding class would then be the
> place where ppl would declare the engine behavior they want for their
> package (strict types, etc). To enforce this, the engine could require th=
at
> the "MyPackage" class implements some interface/extend some base abstract
> class.
>
> Of course, one could hijack a package and declare an unrelated file as
> part of it, but I don't think that's an issue: the situation is the same =
as
> for namespaces, where one can hijack a third party vendor namespace. In
> practice, it proved not being an issue, and the original author's intent =
is
> clear: "this is my namespace/package, if you mess with it, fine, but you'=
re
> on your own".
>
> Nicolas
>

FTR I've created a draft-implementation for a package system here:
https://github.com/php/php-src/pull/4490

It uses a slightly different approach in that it keeps the package name a
string (that should usually match the Composer package name) and uses a
function to register the package.

The main annoyance is that this requires declaring the package in every
file, something I would like to avoid. An alternative I played with is to
allow specifying the package at include time, which would allow the
autoloader to specify which package a file is part. However, while this is
more ergonomic for the user, I'm afraid that this will make static analysis
& IDE scenarios problematic, because they will not be able to easily know
what the package is in cases that fall outside convention. So in the end,
an explicit per-file package declaration may be the best we can do.

Nikita

--00000000000053bdb4058fe7491c--