Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106555
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CAF+90c_R6j0R5jJ5N2VmOSKb_gij6WMH=8h1Qjz+sBUMX11MSA@mail.gmail.com>
Date: Mon, 12 Aug 2019 16:06:43 +0700
Cc: Nicolas Grekas <nicolas.grekas+php@gmail.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A45EFC62-D0E9-4C4E-891B-2EC9BD6DE68A@koalephant.com>
References: <CAF+90c_Ctjja=8fR-uBWL1wDxZge771yMujMhaR_R2seKXciYw@mail.gmail.com>
 <CAOWwgpmsHMjnHuH4tfv_5-0f+pGKv2jJmA5v21FbkdpSHTbTJQ@mail.gmail.com>
 <CAF+90c_R6j0R5jJ5N2VmOSKb_gij6WMH=8h1Qjz+sBUMX11MSA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
From: php-lists@koalephant.com (Stephen Reay)


> On 12 Aug 2019, at 15:26, Nikita Popov <nikita.ppv@gmail.com> wrote:
>=20
> On Mon, Aug 12, 2019 at 10:17 AM Nicolas Grekas <
> nicolas.grekas+php@gmail.com> wrote:
>=20
>> Le lun. 11 d=C3=A9c. 2017 =C3=A0 14:44, Nikita Popov =
<nikita.ppv@gmail.com> a
>> =C3=A9crit :
>>=20
>>> Some time ago I introduced the following proposal for =
namespace-scoped
>>> declares:
>>>=20
>>>   https://wiki.php.net/rfc/namespace_scoped_declares
>>>=20
>>> The idea is to allow specifying declare directives for a whole =
library or
>>> project using:
>>>=20
>>>   namespace_declare('Vendor\Lib', ['strict_types' =3D> 1]);
>>>=20
>>> 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.
>>>=20
>>> The reason why I'm picking it up again is some feedback I received =
for the
>>> 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.
>>>=20
>>> Namespace-scoped declares are perfectly suited to resolve this =
problem. We
>>> can introduce a require_explicit_send_by_ref declare directive to =
make the
>>> 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.
>>>=20
>>=20
>> I've read discussions about the notion of a "package" and the way we
>> should define its boundaries.
>> What about the following?
>>=20
>> Individual files could declare their package using this style:
>> <?php declare(package=3DMyVendor\MyPackage);
>>=20
>> That would be enough to group a set of files together and make them =
share
>> eg some private classes, some optional PHP behaviors, etc.
>>=20
>> 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 that
>> the "MyPackage" class implements some interface/extend some base =
abstract
>> class.
>>=20
>> 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".
>>=20
>> Nicolas
>>=20
>=20
> FTR I've created a draft-implementation for a package system here:
> https://github.com/php/php-src/pull/4490
>=20
> 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.
>=20
> 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.
>=20
> Nikita


Is there some specific benefit to passing an array with `name` and =
`declares` keys, over a signature like either

package_declare(=E2=80=98nikic/php-parser=E2=80=99, strict_types=3D1, =
foo=3Dbar);=20

or even

package_declare('nikic/php-parser=E2=80=99, [=E2=80=98strict_types=E2=80=99=
 =3D> 1, =E2=80=98foo=E2=80=99 =3D> bar]);=20

I realise this is the epitome of bike shedding, it just seems like a =
non-obvious choice (to me at least) to accept a specifically structured =
array?

Cheers

Stephen=