Re: [Discussion] "Internal" attribute and warning

On Mon, May 20, 2024 at 6:58 PM 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 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. > 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 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 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 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 Robert Landers Software Engineer Utrecht NL