(no title)
martijn_himself | 3 months ago
Yes, a lot of great features have been added over the years. But it also introduces some amount of cognitive load and confusion. Take the first new feature in the example:
> Field-backed properties simplify property declarations by eliminating the need for explicit backing fields. The compiler generates the backing field automatically, making your code cleaner and more maintainable.
Huh, I thought we have had this for years, what were they called, ah Auto-Implemented Properties- so why is there a need for this? In this example:
// Automatic backing field with custom logic
public string Name
{
get => field;
set => field = value?.Trim() ?? string.Empty;
}
Ah so it's a way to access the backing field of Auto-Implemented Properties if you need more logic. And in the above can we just say: get;
or do you need to refer to the field keyword explicitly in the getter if we use it in the setter?I feel like the documentation is always somewhat lacking in explaining the reasoning behind new features and how it evolves the language from earlier versions.
xnorswap|3 months ago
You could have:
Or you could have: So you needed in the second case to also declare name as a field. The new syntax avoids having to do that "double" declaration.martijn_himself|3 months ago
Yes, that's right. It is in other words a way to access the compile-time generated backing field for auto-implemented properties. It is quite nice to be honest, I just wish they presented a bit of context in their announcements.
anonymars|3 months ago
I'm thankful I've been along for the ride so I know the "archaeology" but pity those freshly dunked into its increasingly complicated ocean
wvenable|3 months ago