Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123581
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-515-g87b2bad5a-fm-20240604.001-g87b2bad5
Precedence: bulk
MIME-Version: 1.0
Message-ID: <b864dfde-3ae4-4181-9b43-124762e84835@app.fastmail.com>
In-Reply-To: <14f6e0a1-d01b-4dcd-a7d4-f8806ee1db19@app.fastmail.com>
References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
 <CAHSBg45uKCO9R9nrF6c7D1oZsEEwUxkkiRtMoA4fk0ECY--ekw@mail.gmail.com>
 <CP8P284MB21480B5455D962823CF634C593C62@CP8P284MB2148.BRAP284.PROD.OUTLOOK.COM>
 <43606ecd-8838-476d-8fdf-acc6dbe26359@app.fastmail.com>
 <4d4df16b-af35-4245-85f4-016d66e8a4fa@app.fastmail.com>
 <14f6e0a1-d01b-4dcd-a7d4-f8806ee1db19@app.fastmail.com>
Date: Tue, 11 Jun 2024 14:17:44 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Jun 11, 2024, at 1:48 PM, Rob Landers wrote:
> On Tue, Jun 11, 2024, at 15:36, Larry Garfield wrote:
>> On Tue, Jun 11, 2024, at 6:47 AM, Rob Landers wrote:
>>=20
>> > I=E2=80=99m also not a fan of the prefix style, but for different r=
easons. My=20
>> > main reason is that it increases the minimum line-length, potential=
ly=20
>> > forcing you to chop things down into awkward looking lines:
>> >
>> > public
>> > private(set)
>> > string $longvarname {
>> >  get;
>> >  set;
>> > }
>> >
>> > I find that extremely hard to scan, but maybe others do not. The mo=
re=20
>> > natural looking syntax is easier to scan and reason about (IMHO):
>> >
>> > public
>> > string $longvarname {
>> >  get;
>> >  private set;
>> > }
>> >
>> > If I=E2=80=99m having to read the code, I prefer to have everything=
 near where=20
>> > it is used so I don=E2=80=99t have to scroll up to the top and see =
its=20
>> > visibility. Granted, I haven=E2=80=99t used property hooks and I ha=
ve no idea=20
>> > how IDEs will help here; maybe it is a non-issue =E2=80=94 but I gu=
ess people=20
>> > still have to do code reviews which very rarely comes with IDE powe=
rs.
>> >
>> > =E2=80=94 Rob
>>=20
>> I have never in my life seen someone split the visibility to a separa=
te line from the type and variable name in PHP.  I don't know why anyone=
 would start now, especially not because of hooks or aviz.  I just check=
ed and PER-CS very directly states "All keywords MUST be on a single lin=
e, and MUST be separated by a single space."  So splitting it like shown=
 above would be against standard coding conventions anyway.
>>=20
>> This is really a strawman argument.
>>=20
>> --Larry Garfield
>>=20
>
> I=E2=80=99m willing to concede that it might be a straw man, though I =
did not=20
> intend it as such. I was being serious in my pointing out of it=20
> increasing the minimum line length and PER isn=E2=80=99t the only codi=
ng=20
> standard. It may result in some ugly code, as in my example.
>
> =E2=80=94 Rob

I didn't think it was deliberate.  But in practice:

public string $foo;                     // 13 chars, excluding variable.
public readonly string $foo;     // 21 chars, excluding variable.
private(set) string $foo;            // 18 chars, excluding variable.
protected(set) string $foo;       // 19 chars, excluding variable.
public private(set) string $foo  // 24 chars, excluding variable.
public protected(set) readonly string $foo; // 29 chars, excluding varia=
ble.

Even in the most pathologically long case, where you include every possi=
ble modifier, we're up to 29 characters.  Typical coding guidelines say =
to use either 80 or 120 character lines.  So even factoring in indentati=
on, you're still going to need a 50+ character variable name before line=
 length becomes an issue.  At that point, the issue is your silly variab=
le name, not the modifiers.

The far more common cases would be `private(set) string $foo` and `prote=
cted(set) string $foo`, both of which are... shorter than `public readon=
ly string $foo`, which we already have.

In comparison, using hook-embedded style without hook implementations, w=
e get:

public string $foo { private set; } // 29 characters excluding variable

So the base case with hook-embedded style is about 50% more characters t=
han the prefix-style.

The only way that it wouldn't be is to structure it like so:

public string $foo {
  private set;
}

At which point I'd argue that's worse in every regard, especially with h=
ow many properties are now defined in constructor promotion.  That would=
 be vastly uglier in constructor promotion than the inline style, with e=
ither syntax.

To whatever extent we care about line length and conciseness, prefix-sty=
le wins over hook-embedded, unquestionably.

--Larry Garfield