Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123350
Precedence: bulk
MIME-Version: 1.0
References: <CAPzBOBMpOztgNQx35ZnP4c5ZHV-Ax1ETH0=YMzVT9Hq9cdyyDQ@mail.gmail.com>
 <69669f3c-8e9e-4f27-a171-6c341c1d67f7@rwec.co.uk>
In-Reply-To: <69669f3c-8e9e-4f27-a171-6c341c1d67f7@rwec.co.uk>
Date: Sat, 18 May 2024 17:25:06 +0200
Message-ID: <CAPzBOBM2v+8BN=si2y5s-_9_pErwR5Hb0x2g-pQxFHyzrjUcSQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [Discussion] "Internal" attribute and warning
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Sat, May 18, 2024 at 5:18=E2=80=AFPM Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:
>
> On 18/05/2024 15:00, Robert Landers wrote:
>
> I've been thinking about having an "internal" attribute that will emit
> a warning if called from outside it's left-most namespace.
>
>
> I like the general idea, but I don't think limiting to "left-most namespa=
ce" is the best semantics.
>
> It's very common for the top-level namespace to represent a vendor, and t=
he *second* level to be the specific package, e.g. Doctrine\DBAL vs Doctrin=
e\ORM. You've even used that in your example - I presume you've made a typo=
, and meant both examples to be calling PackageA not PackageB. In other cas=
es, there are more levels - e.g. Composer package "doctrine/mongodb-odm" ha=
s root namespace "Doctrine\ODM\MongoDB".

I thought about that too, but in-general, a vendor has the knowledge
and capability to ensure any two packages work together (like Doctrine
plugins in your example).

>
> Possibly the attribute would need some argument to specify its granularit=
y, e.g.  #[Internal('\MyCompany\PackageA')], #[Internal('\Doctrine\ODM\Mong=
oDB')], but that would be annoying to write each time.
>

That could be a useful optional parameter, and might be worth considering.

> This is another case where PHP suffers from its lack of a separate concep=
t of "package" or "module" to scope things to.
>
>
> My second concern is how to implement this efficiently. The check can't h=
appen at compile-time, because we don't know the definition of SomeOtherNam=
espace\Foo; so the check would need to be at run-time when the method/funct=
ion is called. But at run-time, namespaces have very little existence - the=
y really are just part of the names of functions, classes, and constants.
>
> So when calling a marked function, we would have to look up the name of t=
he calling function or the class name of the calling method, and then do a =
string comparison against the namespace constraint. Maybe that would be eas=
y and fast, I don't know.

This is a concern of mine as well, but I'm mostly curious if anyone
even wants this before I worry about implementation details. Right
now, I don't see it being any slower than type-checking, though I
foresee a bit more memory usage to keep track of the caller/callee
namespace.

>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]