Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118996
MIME-Version: 1.0
References: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
In-Reply-To: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
Date: Sun, 13 Nov 2022 18:50:45 -0300
Message-ID: <CADK1yXJkJY57qbmqkHc55S2TyoaxGBt-jN5dPkj8eHv_EGYGrA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009d4c9305ed611fb0"
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: deleugyn@gmail.com (Deleu)

--0000000000009d4c9305ed611fb0
Content-Type: text/plain; charset="UTF-8"

>
>
> 2. `readonly` is a "write once" flag that may be combined with asymmetric
> visibility.  If no set visibility is specified, `readoly` implies
> `private(set)`, but a different set visibility may also be provided.
>
> These are both reasonable rules.  However, it creates a conflict.
> Specifically, in the following cases:
>
> public public(set) readonly string $foo
>
> protected protected(set) readonly string $foo
>

What if the implicit rule for `readonly` is changed into `protected(set)`?
Let's run with this for a minute.

1- It's not truly a CODE breaking change. Right now if you have a
`protected readonly` property, you're either calling the parent constructor
or you're never making use of the variable, otherwise you're getting a
Fatal Error.
2- It's a CONCEPTUAL breaking change. If you've declared a `protected
readonly` property, you may expect anyone in the inheritance chain to be
calling your constructor. A new PHP version will warn you to either change
your property into `protected private(set) readonly` (Rector might be able
to do this) or accept the new behavior.
3- The two logical design choices can be kept.

To be honest, I think asymmetric visibility seems way over complex for very
little benefit, so I'm a bit against the entire feature, but if we were to
have them, it would really be nicer to not have crazy shenanigans involved.

-- 
Marco Deleu

--0000000000009d4c9305ed611fb0--