Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119005
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead
Mime-Version: 1.0
Message-ID: <030202ce-9df6-425d-baa0-c5c2ac8b4760@app.fastmail.com>
In-Reply-To: 
 <CADK1yXJAWG6ZdY++GgQtkW6L23HCLK9cWe3S9bWsfMcdk65bfQ@mail.gmail.com>
References: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
 <CADK1yXJkJY57qbmqkHc55S2TyoaxGBt-jN5dPkj8eHv_EGYGrA@mail.gmail.com>
 <a1382087-69c6-4c43-acb0-cda32a9ed9d7@app.fastmail.com>
 <CADK1yXJAWG6ZdY++GgQtkW6L23HCLK9cWe3S9bWsfMcdk65bfQ@mail.gmail.com>
Date: Mon, 14 Nov 2022 11:50:27 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Nov 13, 2022, at 4:08 PM, Deleu wrote:
>>
>>
>> This is untrue.  You can declare a private property identically in a
>> parent and child class, even readonly.  I'm doing this now in a project.
>> It works, but would be unnecessary if the parent's property were
>> protected(set).
>>
>> --Larry Garfield
>>
>
> I do understand the slight complexity here (perhaps stronger in terms of
> implementation), but my assumption was that if a property is private and
> "the set visibility must be tighter", PHP would never assume `private
> protected(set) readonly`. In other words, if `private readonly` then
> `private private(set) readonly`, therefore nothing changes. You can keep
> the use of disjointed variables in inheritance provided they're all
> private. The only concern is when a property is declared protected, which
> then evaluates to what I mentioned on the previous email.

I don't follow.  Right now, this is legal:

class P {
  protected readonly string $foo;

  public useFoo() {
    if ($this->foo == 'beep') { ... }
  }
}

class C extends P {
  protected readonly string $foo;

  public function __construct(string $foo) {
    $this->foo = $foo;
  }
}

The redeclaration of $foo is necessary because of the implicit private-set on readonly today.  I have code that does this.

If we go with options 1 or 4, then that could be simplified to:

class P {
  protected protected(set) readonly string $foo;

  public useFoo() {
    if ($this->foo == 'beep') { ... }
  }
}

class C extends P {
  public function __construct(string $foo) {
    $this->foo = $foo;
  }
}

This would not require "set is wider", just "set is the same".

If we changed readonly to be an implicit protected(set) instead of private(set), that would also resolve that use case but I do not know if that would cause other problems with code like the above.

> I'm also under the stated assumption that `public public(set) readonly` is
> not something needed to be supported.

I am not aware of any use cases for it, though if it technically becomes possible as a side effect of other changes I don't object.

--Larry Garfield