Re: [Discussion] "Internal" attribute and warning

On Sat, May 18, 2024 at 5:18 PM Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote: > > On 18/05/2024 15:00, Robert Landers wrote: > > I've been thinking about having an "internal" attribute that will emit > a warning if called from outside it's left-most namespace. > > > I like the general idea, but I don't think limiting to "left-most namespace" is > the best semantics. > > It's very common for the top-level namespace to represent a vendor, and the *second* level > to be the specific package, e.g. Doctrine\DBAL vs Doctrine\ORM. You've even used that in your > example - I presume you've made a typo, and meant both examples to be calling PackageA not > PackageB. In other cases, there are more levels - e.g. Composer package > "doctrine/mongodb-odm" has root namespace "Doctrine\ODM\MongoDB". I thought about that too, but in-general, a vendor has the knowledge and capability to ensure any two packages work together (like Doctrine plugins in your example). > > Possibly the attribute would need some argument to specify its granularity, e.g. > #[Internal('\MyCompany\PackageA')], #[Internal('\Doctrine\ODM\MongoDB')], but > that would be annoying to write each time. > That could be a useful optional parameter, and might be worth considering. > This is another case where PHP suffers from its lack of a separate concept of > "package" or "module" to scope things to. > > > My second concern is how to implement this efficiently. The check can't happen at > compile-time, because we don't know the definition of SomeOtherNamespace\Foo; so the check > would need to be at run-time when the method/function is called. But at run-time, namespaces have > very little existence - they really are just part of the names of functions, classes, and constants. > > So when calling a marked function, we would have to look up the name of the calling function or > the class name of the calling method, and then do a string comparison against the namespace > constraint. Maybe that would be easy and fast, I don't know. This is a concern of mine as well, but I'm mostly curious if anyone even wants this before I worry about implementation details. Right now, I don't see it being any slower than type-checking, though I foresee a bit more memory usage to keep track of the caller/callee namespace. > > Regards, > > -- > Rowan Tommins > [IMSoP]