4 ms·

"Constructor property promotion" - so the parameters of your constructor now automatically become properties of the class? So, for saving a few keystrokes in so

• asddubs 4y ago
  they only get promoted if you add private/public/protected before the parameter
  • rob74 4y ago
    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...
    • eropple 4y ago
      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.
    • thecatspaw 4y ago
      from my experience from learning typescript this is really easy to pick up on your own
• naiv 4y ago
  Then just do it. Nobody forces you to use promoted properties
• mrcarrot 4y ago
  > 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.
• acomjean 4y ago
  >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?
  • masklinn 4y ago
    If match was made into a hard keyword, there's no fixing it, it just becomes forbidden as a bareword.
  • rob74 4y ago
    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...
    • moritzwarhier 4y ago
      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
• deleted 4y ago
  [deleted]
• Supermancho 4y ago
  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.
  • Supermancho 4y ago
    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).
    • 8n4vidtmkvmk 4y ago
      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