Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123372
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>
 <CAPzBOBMPXoqtA+axytFhs7jtTkXdra-TvLEOaV2-f9paA9m0Qw@mail.gmail.com> <c5c8448c-c12b-4f3b-8da0-b7770c7f752f@app.fastmail.com>
In-Reply-To: <c5c8448c-c12b-4f3b-8da0-b7770c7f752f@app.fastmail.com>
Date: Mon, 20 May 2024 19:25:04 +0200
Message-ID: <CAPzBOBOpxtcHDdw8Q603itHV69M-uibUXnULymnTHHeO4YoacA@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 Mon, May 20, 2024 at 6:58=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com> wrote:
>
> On Sat, May 18, 2024, at 6:15 PM, Robert Landers wrote:
>
> >> I think an important question to answer here is what we want to have a=
s our definition of "package".
> >>
> >> 1. Should the package be defined by the namespace? If so, anyone can p=
ut code into any namespace; it's not even hard to add to someone else's nam=
espace.
> >> 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 lan=
guages?  Then we'd need a way to define/declare a package on the file syste=
m.  (I have some thoughts there.)  But that may run into performance issues=
, though they could be solved by opcache.  This could also make it harder t=
o inject code into someone else's namespace.  (Whether that's good or bad i=
s 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=
 "implicitly", 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.
>
Hey Larry,

> Understandable, but "easy simple solutions" have a tendency to get in the=
 way of more complete solutions later, or at least cause confusion. So cons=
idering the broader scope is important.  Like, what happens in the future i=
f we have both package visibility (whatever that means) and an #[Internal] =
marker attribute (with whatever details)?  What happens if the attribute's =
namespace doesn't line up with a package?  Which one should we use when, or=
 at that point do we call #[Internal] soft-deprecated?

I think this is something of a moot point. PHP has been around for
30ish years or so. If nobody has championed packages by now ... I
don't think holding back useful features until someone does is a
worthwhile exercise. If we don't like it, we have several options:

0. I'm not necessarily going to work on this now ... and it probably
wouldn't happen until this fall (well after the 8.4 cut off). So,
there's plenty of time to convince me this is a terrible idea.
1. vote "no" before it ever gets past the RFC stage
2. create a competing RFC
3. create an RFC to deprecate/change the functionality afterwards
4. don't use it

Anyway, there are currently only namespaces for organization in PHP.
Any package system would almost certainly use them, so I'm not too
worried about it.

>
> I don't have answers to those, but we would want answers before we added =
the attribute.
>
> > 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.
>
> PS: I absolutely despise it when people use reply-all, and I get two copi=
es of the email in 2 different folders that I have to clean up manually, an=
d if I reply to the wrong one it breaks threading because I'm then replying=
 to a non-list email but sending it to the list.  This is the only list I'm=
 on that has always had that problem.  If people need to communicate faster=
 than email speeds, that's what the dozen available chat media are for.
>
> --Larry Garfield


Robert Landers
Software Engineer
Utrecht NL