4 ms·

This feature has been in C# since about 2.0, and it's been an overall positive. It reduces boilerplate and inconsistencies in different programmers doing the bo

This feature has been in C# since about 2.0, and it's been an overall positive. It reduces boilerplate and inconsistencies in different programmers doing the boiler-plate differently. It also gives static analysis tools semantic information about the structure of your classes. It can group pairs of methods that deal with the encapsulation of fields.

brtkdotse 2y ago
My experience is that 99% of the work related to geters and seters is handled by the IDE
- ok123456 2y ago
  This encapsulation style for OOP is standard; the language should support it and not require additional design patterns or IDE tools. An argument could be made for adding a sigil so the class user knows this isn't a dumb field, but then if someone wants to upgrade a dumb field to this, as Python encourages, they would need to modify every use.
crowcroft 2y ago
I am also in favour of the change. I would argue though that because it's been in C# for so long, then yes it reduces inconsistencies across programmers/codebases, but introducing it to a language as mature as PHP is now though, might not have the same outcome.
- ok123456 2y ago
  I used it immediately in my C# code at the time. It was a breath of fresh air not to have code that looked like "enterprise" java.
signal11 2y ago
It’s interesting to consider the “magic” criticism in the context of languages like Zig, where devs actively want no hidden control flow. And Properties beyond simple { get; set; } are definitely hidden control flow. But as you said — it’s been there in C# for a while and imho it’s a good abstraction over getters and setters. Even 2005-era IDEs could manage it fine, making it easy to access the property’s get/set code, so that it wasn’t really magical. Maybe it’s a culture thing — most C# devs use IDEs. Not sure what PHP devs use, but I suspect tools like PhpStorm will make this easy to work with somehow. Devs using no-LSP editors will likely have a different view.
- amerkhalid 2y ago
  > Maybe it’s a culture thing — most C# devs use IDEs. Not sure what PHP devs use, but I suspect tools like PhpStorm will make this easy to work with somehow. Devs using no-LSP editors will likely have a different view. This is probably one of the big factors. I am also not a huge fan of “magic” even though I use IDE (vscode). I started off as a PHP dev, directly editing files on production server using vi. Any “magic” simply slowed me down. Years later, now I can simply cmd+click to anywhere in code but it feels a bit off to me. Perhaps, I still miss my old days of dev.
  - hakfoo 2y ago
    At my first job, I largely used Notepad++ and grep, and the result tended away from object-oriented code and code paths tended to be not much more than `require_once("common.php");` The second job introduced PHPStorm, and a single page load can bounce through dozens of files and classes; it would probably be untenable without modern tooling.
- neonsunset 2y ago
  How do you expect properties to interact with IDEs? The argument that C# choosing to offer features that lead to terser implementation seems orthogonal to where you write it. Behavior in property getters and setters may as well be completely hidden from the caller. But the standard expectation is that accessing and/or setting a property should be cheap and not involve much logic, which most of the code out there adheres to. (and personally I'm finding it to be a more productive experience than any dynamically typed language which always feels like stone age regardless of the environment)
  - lmm 2y ago
    > How do you expect properties to interact with IDEs? An IDE can highlight non-basic properties in a different colour from basic properties, or underline them or something. That would be difficult for an editor to do as part of normal syntax highlighting.
    - 2y ago
James_K 2y ago
Every step on the path to bloat is justified.
- munk-a 2y ago
  And yet in this wonderful laboratory of a multitude of languages the growth of a language doesn't destroy as much as it offers a larger variety of choice - with good features being stolen by other languages and less good features remaining niche and unique.
  - James_K 2y ago
    Look at C++ or Perl, languages with many features that are quite frequently hated. When you add features, you force users to learn those features. It is not just a "variety of choice" because you know that other people will also take some of those choices and you'll probably have to edit their code at some point. Features are not just added to the language, but imposed on its users. The need to add features to a language is a sign that what you already have is insufficient. Features should be added to the bottom of a language, increasing its expressive power, rather than to the top of the language forming cruft around the edges. It would be much more productive for us to collectively abandon PHP in favour of sane languages, ones which don't require the continual addition of more features to cover their foundational shortcomings.
    - theendisney 2y ago
      The imposed part was funny. I hope I wont have to use anything new. I only had a mild panic attack reading they changed exit() but it was a false alarm. Why is it that after the human life span expires all of the code should be thrown away? I remember when my host updated and php could no longer be opened with <? and my websites spilled their guts all over the screen.
int_19h 2y ago
Properties have been in C# since the very first version. And those, in turn, were largely inspired by Delphi, with the honorable mention of Visual Basic.
jug 2y ago
My favorite feature about properties is that I can set a breakpoint on the setter. It'll now break on anything that sets it with a single breakpoint. Or use "Go to calls" on the setter and I instantly get everything that sets the variable. Of course also works with the getter. Being able to do this, yet only use it as a field is so nice. Other than this, I find properties indispensable in MVVM scenarios so that the view reacts when you set a property. Using getter and setter methods would litter my code so bad that I can't see a "clarity of intent" net positive.

brtkdotse 2y ago

My experience is that 99% of the work related to geters and seters is handled by the IDE

ok123456 2y ago
This encapsulation style for OOP is standard; the language should support it and not require additional design patterns or IDE tools. An argument could be made for adding a sigil so the class user knows this isn't a dumb field, but then if someone wants to upgrade a dumb field to this, as Python encourages, they would need to modify every use.

crowcroft 2y ago

I am also in favour of the change. I would argue though that because it's been in C# for so long, then yes it reduces inconsistencies across programmers/codebases, but introducing it to a language as mature as PHP is now though, might not have the same outcome.

ok123456 2y ago
I used it immediately in my C# code at the time. It was a breath of fresh air not to have code that looked like "enterprise" java.

signal11 2y ago

It’s interesting to consider the “magic” criticism in the context of languages like Zig, where devs actively want no hidden control flow. And Properties beyond simple { get; set; } are definitely hidden control flow. But as you said — it’s been there in C# for a while and imho it’s a good abstraction over getters and setters. Even 2005-era IDEs could manage it fine, making it easy to access the property’s get/set code, so that it wasn’t really magical. Maybe it’s a culture thing — most C# devs use IDEs. Not sure what PHP devs use, but I suspect tools like PhpStorm will make this easy to work with somehow. Devs using no-LSP editors will likely have a different view.

amerkhalid 2y ago
> Maybe it’s a culture thing — most C# devs use IDEs. Not sure what PHP devs use, but I suspect tools like PhpStorm will make this easy to work with somehow. Devs using no-LSP editors will likely have a different view. This is probably one of the big factors. I am also not a huge fan of “magic” even though I use IDE (vscode). I started off as a PHP dev, directly editing files on production server using vi. Any “magic” simply slowed me down. Years later, now I can simply cmd+click to anywhere in code but it feels a bit off to me. Perhaps, I still miss my old days of dev.
- hakfoo 2y ago
  At my first job, I largely used Notepad++ and grep, and the result tended away from object-oriented code and code paths tended to be not much more than `require_once("common.php");` The second job introduced PHPStorm, and a single page load can bounce through dozens of files and classes; it would probably be untenable without modern tooling.
neonsunset 2y ago
How do you expect properties to interact with IDEs? The argument that C# choosing to offer features that lead to terser implementation seems orthogonal to where you write it. Behavior in property getters and setters may as well be completely hidden from the caller. But the standard expectation is that accessing and/or setting a property should be cheap and not involve much logic, which most of the code out there adheres to. (and personally I'm finding it to be a more productive experience than any dynamically typed language which always feels like stone age regardless of the environment)
- lmm 2y ago
  > How do you expect properties to interact with IDEs? An IDE can highlight non-basic properties in a different colour from basic properties, or underline them or something. That would be difficult for an editor to do as part of normal syntax highlighting.
  - 2y ago

James_K 2y ago

Every step on the path to bloat is justified.

munk-a 2y ago
And yet in this wonderful laboratory of a multitude of languages the growth of a language doesn't destroy as much as it offers a larger variety of choice - with good features being stolen by other languages and less good features remaining niche and unique.
- James_K 2y ago
  Look at C++ or Perl, languages with many features that are quite frequently hated. When you add features, you force users to learn those features. It is not just a "variety of choice" because you know that other people will also take some of those choices and you'll probably have to edit their code at some point. Features are not just added to the language, but imposed on its users. The need to add features to a language is a sign that what you already have is insufficient. Features should be added to the bottom of a language, increasing its expressive power, rather than to the top of the language forming cruft around the edges. It would be much more productive for us to collectively abandon PHP in favour of sane languages, ones which don't require the continual addition of more features to cover their foundational shortcomings.
  - theendisney 2y ago
    The imposed part was funny. I hope I wont have to use anything new. I only had a mild panic attack reading they changed exit() but it was a false alarm. Why is it that after the human life span expires all of the code should be thrown away? I remember when my host updated and php could no longer be opened with <? and my websites spilled their guts all over the screen.

int_19h 2y ago

Properties have been in C# since the very first version. And those, in turn, were largely inspired by Delphi, with the honorable mention of Visual Basic.

jug 2y ago

My favorite feature about properties is that I can set a breakpoint on the setter. It'll now break on anything that sets it with a single breakpoint. Or use "Go to calls" on the setter and I instantly get everything that sets the variable. Of course also works with the getter. Being able to do this, yet only use it as a field is so nice. Other than this, I find properties indispensable in MVVM scenarios so that the view reacts when you set a property. Using getter and setter methods would litter my code so bad that I can't see a "clarity of intent" net positive.