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:
>>
>> > I’m also not a fan of the prefix style, but for different reasons. My
>> > main reason is that it increases the minimum line-length, potentially
>> > 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 more
>> > natural looking syntax is easier to scan and reason about (IMHO):
>> >
>> > public
>> > string $longvarname {
>> > get;
>> > private set;
>> > }
>> >
>> > If I’m having to read the code, I prefer to have everything near where
>> > it is used so I don’t have to scroll up to the top and see its
>> > visibility. Granted, I haven’t used property hooks and I have no idea
>> > how IDEs will help here; maybe it is a non-issue — but I guess people
>> > still have to do code reviews which very rarely comes with IDE powers.
>> >
>> > — Rob
>>
>> I have never in my life seen someone split the visibility to a separate 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 checked and PER-CS
>> very directly states "All keywords MUST be on a single line, and MUST be
>> separated by a single space." So splitting it like shown above would be
>> against standard coding conventions anyway.
>>
>> This is really a strawman argument.
>>
>> --Larry Garfield
>>
>
> I’m willing to concede that it might be a straw man, though I did not
> intend it as such. I was being serious in my pointing out of it
> increasing the minimum line length and PER isn’t the only coding
> standard. It may result in some ugly code, as in my example.
>
> — 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 variable.
Even in the most pathologically long case, where you include every possible
modifier, we're up to 29 characters. Typical coding guidelines say to use
either 80 or 120 character lines. So even factoring in indentation, 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 variable name, not the modifiers.
The far more common cases would be `private(set) string $foo` and
`protected(set) string $foo`, both of which are... shorter than `public
readonly string $foo`, which we already have.
In comparison, using hook-embedded style without hook implementations, we get:
public string $foo { private set; } // 29 characters excluding variable
So the base case with hook-embedded style is about 50% more characters than 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 how many
properties are now defined in constructor promotion. That would be vastly
uglier in constructor promotion than the inline style, with either syntax.
To whatever extent we care about line length and conciseness, prefix-style wins
over hook-embedded, unquestionably.
--Larry Garfield
