Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106552
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:27:23 +0200
Message-ID: <CABdc3WrUf-LTL7ru_ArGXt3YcMEJERwh81nds4SctP6EBwEE2g@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d2b62a058fe74b24"
Subject: Re: [PHP-DEV] [RFC] Namespace-scoped declares, again
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--000000000000d2b62a058fe74b24
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Nicolas,

pon., 12 sie 2019 o 10:17 Nicolas Grekas <nicolas.grekas+php@gmail.com>
napisa=C5=82(a):

> 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 =
or
> > 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 forwar=
d
> > with it.
> >
> > 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 thi=
s
> > 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
> 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.
> >
>
> I've read discussions about the notion of a "package" and the way we shou=
ld
> 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.
>
>
Why suggesting use of declare for that?
Wouldn't a new "package" keyword be more appropriate for that?
For eg.:
<?php
package MyVendor\MyLib;

I was also thinking about it to be a part of FQCN cause PHP would figure
out package name from
namespaced symbol names.

Was even thinking about writing generic RFC for packages we could discuss
on and redirect discussion
into package related topic.


> 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 pa=
rt
> of it, but I don't think that's an issue: the situation is the same as fo=
r
> 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
>


--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
about.me/brzuchal
brzuchalski.com

--000000000000d2b62a058fe74b24--