On 30 May 2025, at 18:38, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote:
> 
> On 30 May 2025 08:57:34 BST, Rob Landers <rob@bottled.codes> wrote:
>> 
>> I’m starting to think that maybe modules might be a bad idea; or at least, 
>> class/module visibility.
>> 
>> As an anecdote, I was looking to extract a protobuf encoding library from a 
>> larger codebase and create a separate library for Larry’s Serde library. 
>> During the extraction I realized that many of the classes and functions I 
>> was relying on actually used @internal classes/functions. If “module” 
>> visibility were a thing… would my implementation have been possible?
>> 
>> In other words, if visibility comes with modules; there really needs to be 
>> some kind of escape hatch. Some way to say, “I know what I’m doing, so get 
>> out of my way.”
> 
> 
> Isn't this exactly the same as any other "access control" feature?
> 
> We have private/protected methods and properties, final methods and classes, 
> readonly properties; other languages also have sealed classes, module and/or 
> file private, etc. All of these are ways for the author of the code to 
> express how they intend it to be used, and to protect users against 
> *accidentally* violating assumptions the code is relying on.
> 
> They are of course not *security* measures, as they can be bypassed via 
> Reflection or just editing the source code.
> 
> If you're using someone else's code in ways they didn't intend, that's up to 
> you, but you may need to make changes to do so, i.e. fork it rather than 
> relying on the distributed version. 

If the goal is to hint consumers of a library about the (lack of) guarantees 
regarding a method or its signature, then perhaps an `#[\Internal]` attribute 
makes sense.

```php
namespace Acme\Foo;

class Foo
{
    #[\Internal('Acme')]
    public function bar() { /* ... */ }
}
```

In the example above, I image calling or extending the `Foo::bar()` method from 
somewhere outside the `Acme` namespace would trigger an E_USER_WARNING or 
E_USER_NOTICE. The warning/notice could then be suppressed when explicitly 
overriding an `#[\Internal]` method with `#[\Override]`.

Alwin

Reply via email to