On Sat, May 18, 2024 at 7:58 PM Larry Garfield <la...@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 our
> 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 namespace.
> 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 languages?
> 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, though
> they could be solved by opcache. This could also make it harder to inject
> 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
> "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.
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.
