Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123370
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-480-g515a2f54a-fm-20240515.001-g515a2f54
Precedence: bulk
MIME-Version: 1.0
Message-ID: <c5c8448c-c12b-4f3b-8da0-b7770c7f752f@app.fastmail.com>
In-Reply-To: 
 <CAPzBOBMPXoqtA+axytFhs7jtTkXdra-TvLEOaV2-f9paA9m0Qw@mail.gmail.com>
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>
Date: Mon, 20 May 2024 15:31:31 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Discussion] "Internal" attribute and warning
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

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 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.

Understandable, but "easy simple solutions" have a tendency to get in the way of more complete solutions later, or at least cause confusion. So considering the broader scope is important.  Like, what happens in the future if 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 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 copies of the email in 2 different folders that I have to clean up manually, and 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