On Mon, May 20, 2024 at 6:58 PM Larry Garfield <la...@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
