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
