Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123458
Precedence: bulk
MIME-Version: 1.0
References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
In-Reply-To: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
Date: Wed, 29 May 2024 21:53:41 +0200
Message-ID: <CAB-Bujb7MJ_+t7F1=EF5gKTgKsm44JnAUinN4nnwBf52q1iwrg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: andreas@dqxtech.net (Andreas Hennings)

Hello Larry,
just a quick thought.
Is there a reason why we cannot just make it "public private string
$x" instead of "public private(set) string $x"?
We would define that the second visibility specifier is for write.

The current proposal with "public private(set)" is less ambiguous, and
it is immediately obvious that this is something new, and not just
somebody accidentally added two modifiers.
At the same time, it feels a bit alien and cluttered.

Other options could be something like "public:private" or "public-private".

A consequence of such options would be that you always need to specify
the read visibility along with the write visibility.
But this seems ok to me.

This is not a final opinion, just a thought.

-- Andreas

On Wed, 29 May 2024 at 21:17, Larry Garfield <larry@garfieldtech.com> wrote:
>
> As promised, Ilija and I offer this revised version of asymmetric visibility.
>
> https://wiki.php.net/rfc/asymmetric-visibility-v2
>
> It's still essentially the same as last year's version, but with a few adjustments and changes:
>
> * readonly properties are now supported in a logical fashion.
> * We've brought back the abbreviated form, as public-read, something else set is the most common use case.
> * The section on magic methods has been greatly simplified.  The implementation itself hasn't changed, but the explanation is a lot less confusing now.
> * We've explained how aviz interacts with hooks (they don't, really) and with interface properties (in the obvious way), which didn't exist at the time of the last draft.
> * We've added a section with examples of how aviz is a concrete improvement, even in a world with readonly and hooks.
> * We've added a section discussing why the prefix-style syntax was chosen.
>
> *dons flame retardant suit*
>
> --
>   Larry Garfield
>   larry@garfieldtech.com