On 25 March 2025 21:23:48 GMT, Rob Landers <rob@bottled.codes> 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]
