Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118381
MIME-Version: 1.0
References: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
 <CABdc3WqQ-kLTa3C=61_=yW-yJZuP2p_QW1TNe12WuHHur7aHng@mail.gmail.com>
 <e122e44f-550e-4089-8100-a27df9f8c9fa@www.fastmail.com> <CAKxcST_Mu3qDKKLgtsBBVAm=6mLirhjZ-88f+jjWeNhWyzO16A@mail.gmail.com>
 <A78DA1F7-1F74-4A94-962C-0EA5979431AD@gmail.com> <CANS-=pfq1Q+aK6CWTGKpiSH_M4PABQwb-65HqznDw_xzoDM8+Q@mail.gmail.com>
 <a6bc6a0a-912e-4c0f-9571-7fb920f1d90c@www.fastmail.com>
In-Reply-To: <a6bc6a0a-912e-4c0f-9571-7fb920f1d90c@www.fastmail.com>
Date: Mon, 8 Aug 2022 10:09:10 +0200
Message-ID: <CABdc3WpVqoh3=Fczaa_A2seQm3omfj74KJDiAM85O7qLMh9s+Q@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005344d905e5b65599"
Subject: Re: [PHP-DEV] [RFC] Asymmetric visibility
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--0000000000005344d905e5b65599
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Larry,

niedz., 7 sie 2022 o 21:02 Larry Garfield <larry@garfieldtech.com>
napisa=C5=82(a):

> On Sun, Aug 7, 2022, at 5:54 AM, Lynn wrote:
> > On Sun, Aug 7, 2022 at 12:34 PM Rowan Tommins <rowan.collins@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 yo=
u
> >> 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 abo=
ut
> > 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 somewher=
e.
>
> 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=E2=82=
=AC

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=C5=82 Marcin Brzuchalski

--0000000000005344d905e5b65599--