Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123357
Precedence: bulk
MIME-Version: 1.0
References: <CAPzBOBMpOztgNQx35ZnP4c5ZHV-Ax1ETH0=YMzVT9Hq9cdyyDQ@mail.gmail.com>
 <407efbd0-2d9c-4bcb-b795-0ee326728415@heigl.org> <864f67fb-01a5-49a6-9f81-b54600046652@app.fastmail.com>
In-Reply-To: <864f67fb-01a5-49a6-9f81-b54600046652@app.fastmail.com>
Date: Sat, 18 May 2024 20:15:59 +0200
Message-ID: <CAPzBOBMPXoqtA+axytFhs7jtTkXdra-TvLEOaV2-f9paA9m0Qw@mail.gmail.com>
Subject: Re: [PHP-DEV] [Discussion] "Internal" attribute and warning
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <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 7:58=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com> wrote:
>
> On Sat, May 18, 2024, at 11:06 AM, Andreas Heigl wrote:
> > Hey all.
> >
> > Am 18.05.24 um 16:00 schrieb Robert Landers:
> >> Hello internals,
> >>
> >> I've been thinking about having an "internal" attribute that will emit
> >> a warning if called from outside it's left-most namespace.
> >>
> >> It might look something like this:
> >>
> >> namespace MyCompany\PackageA {
> >>    #[\Internal] function doStuff() {}
> >> }
>
> *snip*
>
> I think an important question to answer here is what we want to have as o=
ur definition of "package".
>
> 1. Should the package be defined by the namespace? If so, anyone can put =
code into any namespace; it's not even hard to add to someone else's namesp=
ace.
> 2. Should the package be implicit, or explicit?  If it's a namespace, is =
it auto-implicit or an "empty" package?
> 3. Should package be defined/implied by the file system, like many langua=
ges?  Then we'd need a way to define/declare a package on the file system. =
 (I have some thoughts there.)  But that may run into performance issues, t=
hough they could be solved by opcache.  This could also make it harder to i=
nject code into someone else's namespace.  (Whether that's good or bad is a=
 matter of opinion.)
>
> The proposed attribute would be going with point 2, implicitly.  That may=
 be a useful approach, I don't know, but it's not something we should do "i=
mplicitly", lest it cause issues for us in the future.
>
> --Larry Garfield

Oof, I wasn't trying to open the "what is a package" can of worms,
though that may need to happen sooner-or-later. I was mainly trying to
be able to mark malleable APIs and set a conservative delimiter
(top-level/root namespace) for the warning. I think being able to
specify a more local delimiter (working on teams in large codebases)
might also be useful.

I don't really see an issue with injecting code into other namespaces,
though. That's basically the only way to properly implement proxies,
afterall.

Robert Landers
Software Engineer
Utrecht NL

PS pro-tip: use reply-to-all to email the original author of the email
as well. I saw this email almost two hours ago on another email
address I'm subscribed with but couldn't reply until now. If you also
email the original author, we can communicate faster (for whatever
that is worth) while the list plays catch-up.