Hacker News Reader

Comment by rob74 | Hacker News Reader

"Constructor property promotion" - so the parameters of your constructor now automatically become properties of the class? So, for saving a few keystrokes in some cases, they have introduced a feature that I imagine is extremely confusing if you're not familiar with it (parameters go in, and then nothing happens with them - whaaat)? And what if I don't want to have my constructor parameters as properties, maybe because I process them somehow in the constructor, and set some other properties instead?

And a colleague of mine is a huge fan of the new "match" keyword - he's working on a sports management application, and of course he had a "Match" class, used everywhere, which he had to rename...

View on HN

> And what if I don't want to have my constructor parameters as properties, maybe because I process them somehow in the constructor, and set some other properties instead?

Then you don't use property promotion. It's optional: it only happens if you add a visibility modifier before the parameter name.

they only get promoted if you add private/public/protected before the parameter

Ah, ok, yeah, thanks, guess that makes sense :) - and may also give someone who doesn't know this feature a hint as to what's going on...

Beyond that, this is becoming more and more common in other languages. Anyone who ever touches TypeScript will immediately recognize it, for example, or (with a bit more of a stretch) Java/C#/Kotlin/Scala data classes and records.

Feature convergence is only a bad thing if you're not spending enough time in other tools to recognize them.

from my experience from learning typescript this is really easy to pick up on your own

Re: Constructor property promotion

Class Access Modifiers (mixin selectors) are now potentially/usually going to be in 2 places. The object level and the constructor level. Property promotion will land somewhere in PHP-FIG eventually as recommended or not, and then you'll have to know it regardless of how often you use it. Ironically, PHP is feeling (and looking!) more and more like Perl.

Java has inspired auto getter/setter support in the IDE (even PHP IDEs), so why does this need to be a feature instead of an IDE extension to type it for you at the class level? To be fair, @AllArgsConstructor is a thing and it's been great for Java, which is meaningfully different and more succinct. I guess I can give a minimal kudos for not making it an annotation. shrug

Re: Union Types, Unpacking, Enums, et al aren't bad, although I have smaller issues with some of it. What I think doesn't matter that much as I don't think I'll ever go back to PHP, despite decades of experience with it.

Development is primarily about automation, so I expect more and more tooling support to aid in working with more complex applications that have grown to absurd sizes (in terms of LoC). I expect, long after I'm dead, all languages will be tightly bound into IDEs, bringing us full circle (LISP, erlang, et al).

i don't think so. we're moving towards language servers, so as long as your ide speaks langserver, you'll have a few choices

>And a colleague of mine is a huge fan of the new "match" keyword - he's working on a sports management application, and of course he had a "Match" class, used everywhere, which he had to rename...

Namespace?

If match was made into a hard keyword, there's no fixing it, it just becomes forbidden as a bareword.

Well yeah, I guess he could have prefixed every usage of the class with the namespace, but probably decided to rename it to have less verbose code...

This would be unneeded if PHP wouldn't have case-insensitive identifiers, right?

But such a breaking change would of course be too much to ask

Then just do it. Nobody forces you to use promoted properties

Reply on news.ycombinator.com