Hacker News Reader

Comment by ok123456 | Hacker News Reader

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.

View on HN

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.

> 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.

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.

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)

> 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.

This is also a problem when reviewing changes through github-like workflows, and even more with patch-based workflows. It's probably either impossible or very difficult to fix that ever.

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.

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.

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.

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.

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

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.

Every step on the path to bloat is justified.

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.

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.

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.

Reply on news.ycombinator.com