On Tue, Mar 25, 2025, at 3:29 PM, Rob Landers wrote:
> File-private, in my mind, is different; such as when the classes are
> distinctly unrelated with respect to each other, but nobody else should
> be able to instantiate or use the private class. It is like it doesn't
> exist outside that file. For example, something like a log formatter or
> a default strategy implementation. Personally, I'd feel that
> file-private should be kept as simple as possible and limit it to
> "top-level" things, but that doesn't necessarily have to be the case.
> If we did allow it on methods/properties, when mixing it with regular
> visibility, what happens? fileprivate public private(set) ... means
> what exactly? I assume we probably wouldn't allow that particular
> scenario, and maybe fileprivate on a property means public in the
> file, but private outside the file. But then how would that intersect
> with inheritance? My point is that I don't think there is an intuitive
> answer to these behaviors, but at least nested/inner classes, while not
> 100% intuitive either, at least are available in other languages, so
> its behavior will be familiar.
The aviz RFC was designed explicitly to support this sort of case. :-) (Module or file visibility.)
The syntax was borrowed from Swift, which has 5 levels: public, package, internal (within the same
module, which is apparently not the same as a package), file-private, and private.
The syntax for a visibility modifier is
$accessLevel($operation)
If the $operation is omitted, it means "any operation not otherwise specified." Right now
the only explicit operation is set, though there's no reason get
couldn't be made available on its own, too. We didn't, because right now there's no
reason *to* do it, either. :-) But the logical structure is there.
If we add more access levels, we just have more options for that part of the modifier. If we add
more operations, we just have more options for that modifier.
So if, hypothetically, we added a module visibility between public and protected, and
added support for controlling the ability to unset() a property separately from setting it (for
whatever reason, bear with me), the syntax extends to that quite naturally:
public fileprivate(set) private(unset) string $foo;
(With the standalone public still being optional.)
Methods only have one action, call, so there's no aviz to consider. Just fileprivate
function foo(int $a) { ... }.
There may be other edge cases and gotchas to consider (eg, traits, as you note), but the syntax to
use is already defined.
--Larry Garfield