Hi Larry,
niedz., 7 sie 2022 o 21:02 Larry Garfield <la...@garfieldtech.com>
napisał(a):
> On Sun, Aug 7, 2022, at 5:54 AM, Lynn wrote:
> > On Sun, Aug 7, 2022 at 12:34 PM Rowan Tommins <rowan.coll...@gmail.com>
> > wrote:
> >
> >> Can you expand on where you think the ambiguity / implicitness is? As I
> >> understand it, the RFC is proposing exactly three new combined access
> >> levels:
> >>
> >> - "public private(set)"
> >> - "public protected(set)"
> >> - "protected private(set)"
> >>
> >> Although aesthetically it will take a bit of getting used to, it seems
> to
> >> me pretty clear that the first means "mostly public, but private if you
> >> want to set it", and so on.
> >>
> >> The only thing I can think of that could be described as "implicit" is
> >> that accessing a property by reference is considered a "set" operation,
> >> which I'm not sure how any implementation could avoid.
> >
> >
> > Personally for me it's the syntax. Reading "public private", "public
> > protected", or "protected private" reads really weird `public
> private(set)
> > static self $property`. In the end it makes sense if you know what it
> > means, otherwise it's probably confusing. I really like this RFC and I
> feel
> > like this might just be the way to go forward, but I have my doubts about
> > how many more keywords can be realistically added before it becomes a
> > problem.
>
> What syntax would avoid having the visibility keyword repeated? if you
> want "public get, private set" behavior, I don't know how that could be
> done without having the words "public" and "private" both appear somewhere.
>
> Also note, since using private(set) is mutually exclusive with readonly,
> that the resulting keyword list is about the same length as the existing
> "public readonly string $foo" that has cropped up frequently with PHP 8.1.
> So... yes it's another keyword, but it's not more keywords that can exist
> simultaneously. And moving the keyword to the right (a la C#) wouldn't
> make it any shorter; if anything it would be even more keystrokes.
>
> Very close in size, same in complexity:
>
> public readonly string $foo
> public private(set) string $foo
>
Since the radio request show already started wanted to push my 0.50€
Instead of thinking how to improve visibility on the left side, let's move
all the visibility modifiers to the right
but enclosed with parentheses, this way a future stays open for
improvements and introduction of accessors.
// instead of
class Foo {
public private(set) static int|string $id;
}
// let's do this
class Bar {
static int|string $id {
public;
private set;
};
}
A future improvement may add an accessor body on the right side of "set".
Cheers :D,
Michał Marcin Brzuchalski
