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
