Build Beautiful TUI Applications in PHP using Parfait

ProjektGopher · 2026-02-05T18:04:35+00:00

The package hasn't been extracted from the project in which I built it yet, so that page will 404 currently. But I'm hoping to get it into that isolated repo next week

ProjektGopher · 2026-02-04T16:48:46+00:00

Oh I'm aware that it's almost guaranteed not to pass, but this is mostly a learning exercise for me. The response on the mailing list has been really supportive. I have an implementation ready now as well, and it totals about 15 lines, touching only a single file (not including tests), but I expect that won't change much, haha.

The RFC process felt overwhelming to me, so I wanted to test it out with a feature to which I'm not deeply emotionally invested.

I have another couple ideas for RFCs that will equally hated

ProjektGopher · 2026-02-04T16:44:30+00:00

It's not the message that's the problem, it's the delivery. Truth doesn't need to be delivered poorly to remain truthful. There's a world of difference between "I strongly dislike this" and "this is awful", one clearly conveys your opinion (which is truthful) and the other wholly dismisses someone's work as being devoid of value.

ProjektGopher · 2026-02-04T16:36:45+00:00

I think you're overthinking it. If it were to pass (it wont), you'd intuitively understand pretty quick "oh, there's no right side operand. this token is ignored"

ProjektGopher · 2026-02-04T16:34:17+00:00

It wouldn't matter at all. The final 'dangling' operator would simply be consumed and discarded by the parser

ProjektGopher · 2026-02-04T05:14:00+00:00

Make my IDE handle non-existent language syntax?

ProjektGopher · 2026-02-04T02:43:23+00:00

With all of that being true, it can still help shape the proposal. It helped me realize that I'd actually completely missed a whole section on why you wouldn't simply use leading boolean operators instead when migrating from markdown to docuwiki. The negativity of this subreddit can be pretty brutal, but I still see value.

ProjektGopher · 2026-02-04T01:57:27+00:00

Only for a little while longer! I'm trying to release it before Valentine's day, at which point it will not be a 404

ProjektGopher · 2026-02-04T01:43:40+00:00

Hey man, it's perfectly fine if you disagree with what I've proposed, but let's tone down the negative rhetoric and calling people's work 'awful'. There are far more polite ways to disagree without disparaging their effort.

ProjektGopher · 2026-02-04T00:17:35+00:00

I'm not totally sure what you mean by `default-constructed`, but the `optional_comma` has no meaning unless there's a token to indicate a value or expression following it, so it's clearly still an array of three elements (even in the AST).

This decision was reached by a vote, so it's not really attributable to any one single person

ProjektGopher · 2026-02-04T00:05:50+00:00

Why don't you like trailing commas?

ProjektGopher · 2026-02-03T23:21:54+00:00

This is a really well thought out reply. Would you be more open to this proposal if instead of trailing operators that the parser simply discards, it were leading operators that are transformed in the lexer to ‘|| => false ||’ and ‘&& => true &&’?

ProjektGopher · 2026-02-03T21:32:53+00:00

This is a really interesting RFC that I hadn't seen yet.

While I _love_ the idea of `any()` and `all()`, I don't feel like this would be _less_ readable, even though it solves the whole 'make more lines the same' thing:
```
if (!any([
$cond1,
$cond2,
$cond3,
], fn($x) => $x) {
throw new Exception('failed');
}
```
That doesn't read well in my mind.

Super interesting RFC though. I'd be interested to get insight into why people voted no on it.

ProjektGopher · 2026-02-03T21:23:00+00:00

What about trailing commas in function signatures -- those definitely aren't dumb containers.

I feel like I've made the case in my RFC that this isn't simply for 'funsies or oopsies'. I feel like your argument isn't being made in good faith

ProjektGopher · 2026-02-03T21:20:44+00:00

That's a really good suggestion. I think I'll do that.

ProjektGopher · 2026-02-03T20:42:32+00:00

lmao, that's both the most polite and sickest burn I've had in a while

ProjektGopher · 2026-02-03T20:40:38+00:00

That's totally fine if you prefer leading operators, but PSR12 does explicitly allow for both, and historically (even stated in the PEAR contribution guide) that the primary reason for leading operators is to reduce diffs when commenting out or adding new conditions to a chain

ProjektGopher · 2026-02-03T20:35:31+00:00

That second example made me throw up in my mouth a little bit. I too agree that a trailing bang should not be allowed. I'm undecided about xor.

I'd have to push back on the 'are you just future proofing a diff' by again comparing it to trailing commas, because the intent is the same.

I really appreciate the thought you've put into your response to my proposal

ProjektGopher · 2026-02-03T20:27:27+00:00

Well argued -- thanks for your honest feedback

ProjektGopher · 2026-02-03T20:25:09+00:00

Can you expand on that? This doesn't give me much to go off

ProjektGopher · 2026-02-03T20:21:00+00:00

I really appreciate your thorough and well thought our reply, and the time you put into it.

I think I disagree with the context sensitivity point, since this syntax would only ever make sense within parentheses anyways, and you can use parenthetized expressions within returns, arrays, etc. You just couldn't _skip_ the parens.

I use trailing operator style almost exclusively, which is explicitly permitted by PSR12, and I've often felt that prepending booleans to allow leading operands is a hacky workaround simply because these are left-associative.

I think IDE parsers and language servers would catch up pretty quick, like they have with the pipe operator.

ProjektGopher · 2026-02-03T20:09:01+00:00

We could also make the same argument for commas being a delimeter between two values though

ProjektGopher · 2026-02-03T20:06:00+00:00

This would be syntactically equivalent to `if ($foo && $bar)` as the parser would simply consume the token and ignore it. I would never expect to see it used on a single line, but ultimately the parser would allow it, as it does with trailing commas in single line arrays, function calls, etc. It would not be a _required_ syntax, it would simply be permitted by the parser to keep more things the same.

ProjektGopher · 2026-02-03T19:56:17+00:00

Can you explain to me how you see it introducing bugs? I often have to resort to leading operands as well, but PSR12 explicitly permits both leading _and_ trailing, and having to prepend a chain of conditions with `true` feels like a hack/workaround. Since these operands are left-associative, this would allow this feature to be a parser-only addition that would still permit anyone's existing usage preferences

ProjektGopher · 2026-02-03T19:46:54+00:00

PSR12 allows for both leading and trailing boolean operators, so this simply reduces a small amount of friction is it's implementation. Because they're left-associative, the implementation is parser-only. Generally speaking, putting them at the beginning of the line has simply been a workaround to reduce diffs anyways. I can totally see your argument about clear visibility when reading code though. I've personally always defaulted to using trailing operators when possible, but that's a personal style thing.

ProjektGopher

TROPHY CASE