On 25 March 2025 21:23:48 GMT, Rob Landers <[email protected]> wrote:
>
>> If we didn't have "protected", would you ask the same about "protected
>> private"? "fileprivate" would be just another access level, not something you'd
>> combine with existing ones.
>
>Actually, probably yes :) Mostly just to ask for clarification. In this case though, we have
>private(set) and protected(set); would we also want fileprivate(set)? That's what I was getting
>at. How do we mix/match up all these things?
I don't see what needs deciding - private(set) isn't a new access level, it's
basically sugar for a setter that's marked private.
Try replacing "private" with "level1", and "protected" with
"level2":
level1(set) level2(get) int $foo;
And then add "level1a"; can you use it in the same places? Of course:
level1a(set) level2(get) int $foo;
So why would there be any ambiguity about writing this?
fileprivate(set) protected(get) int $foo;
>> > maybe fileprivate on a property means public in the file,
>> > but private outside the file. But then how would that intersect with inheritance?
Just to call back to this: it's like saying "protected means public inside the class and
its descendants, but private everywhere else". It's an unnecessarily confusing way of
describing it, because you then have to define "public" and "private" without
the definitions being recursive.
A more straightforward description is "protected means accessible inside the class and its
descendants, and nowhere else".
Maybe having "private" in the name is putting you off, and this is clearer:
samefile(set) samemodule(get) int $foo;
No "private" or "public" involved anywhere, just descriptions of where the
property can be accessed.
>> I see no reason for inheritance to be involved at all. If we want an access level that
>> means "accessible from any code in this file, or any subclass of the current type", we can
>> make up a keyword for that as well - "fileprotected", or
>> "fileprivate_or_protected", or whatever.
>
>Inheritance gets involved in traits. Traits do "inherit" private access properties
>(currently): https://3v4l.org/89I7A
Traits don't inherit anything, and they don't restrict anything either. They paste code
in, and once pasted it acts like it was written in the new location. You can even change access
levels while pasting, with the syntax "use Foo { bar as public }".
The "private" keyword in your example is pasted into class Foo, and means "accessible
within class Foo". It never applies any restriction relative to trait Bar, because running code
never belongs to the trait.
A "fileprivate"/"samefile" keyword would be pasted into the file it was used in,
and mean accessible within that file; it wouldn't matter what file the trait was defined in. It
would probably be useless, but lots of useless code is possible in any language.
Besides, all these questions have to be answered for nested classes as well. Just because
you've reused the keyword "private" rather than adding "private_or_nested",
you still have to define exactly what it does and doesn't allow access from in these new
scopes.
Rowan Tommins
[IMSoP]