I didn’t talk about who originated the concept but rather showed what problem it tries to solve

@@nickchapsas Sure that. I just wanted to point out, that Dephi had this before Java, or C# for that matter. I was a Delphi developer since its v2-v3... back in 1995, and I loved its property concept... missing elsewhere. And I was glad to see it appear and evolve in C#.

Delphi had properties since it’s inception (ie; V1). It was actually quite an advanced language.

@@matthewwood4756 It still is 🙂

More realistically - next target would be 250k ;-)

Semi-auto properties using the "field" keyword seem to be coming in C# 11.

There are attributes that add behaviour and can’t be applied on a property by design so you can use the field thing to apply it on the field

@@nickchapsas ooookay, I am seeing how it would be used now. Thanks for the poke in the right direction. It would seem (to me) to be a rare case outside of perhaps complier / src generator related work where you might need that if I am understanding correctly. Otherwise I think it would raise red flags for me due to the complexity of its inclusion / usage / chance of breaking in a future version / change if you are coupling so tightly to generated code otherwise.

@@nickchapsas right, but ObsoleteAttribute on an automatic backing field would seem to be useless, because the field cannot be directly accessed in C# code. I could see the attribute as possibly being useful via reflection for some purpose, but otherwise I can't see what effect [field: Obsolete] would have on a property.

@@shakerlakes You think so but in C# 11 we're finally getting access to those hidden backing fields through the 'field' keyword :)

@@dhkatz_ I read up on the C#11 field keyword and it seems pretty interesting, but since it's only available inside the getter and setter, I'm wondering what the value would be of marking the backing field Obsolete while keeping the property *not* Obsolete. The warning would only apply inside the getter or setter, which is a very odd situation. Since the lexical scope of a backing field is very small -- only inside the getter and setter -- it seems a bit silly to me to mark it as Obsolete only to use it a few lines later. Obsolete is generally most helpful as a signal to "outsiders" -- *callers* of a function or users of a property -- that the feature should not be used. But to declare something in a tiny local scope as Obsolete? I can't see a use case for it. It would be like the following code -- if the language allowed us to set attributes on variables: [Obsolete] int x; x = 3; // triggers a compiler warning

Is that to expand on records?

@@R.B. Not really. It's just going to finally complete auto getters and setters. Like how set implictly can access 'value'. Well now get and set will both have an implicit 'field'' that you can read and write to as if it were a backing field. No more need to do: private string _foo = ""; public string foo { get; set => _foo = value; }; Instead it's just public string foo { get; set => field = value; } = "";

@@dhkatz_ oh yeah. I do remember that being discussed in one of the talks.

@@dhkatz_ Thanks for explaning

There are cases where a library might have a usage limitation on fields only which means you can’t use it on properties directly.

@@nickchapsas That makes sense. The only cases I could think of was to tag the backing field itself with `JsonProperty` so you can get away with no setters (assuming that works). And to tag it for C#10's Source Generators.

You mean throw an exception if it's not set? If so, .NET 7 has a new keyword "required" that you can mark the property with. It'll be a compile time error not to initialize the property when you create the object.

@@phizc sorry for misconfuse but I mean not throw exception; but not using ctor's with N-amount arguments.

I'd love to but it hasn't evolved that much actually since it was released

@@nickchapsas thanks nick, I guess the other video about dynamic will do for now. Thanks again, for this video I can now share more details about models/properties.

If you’re setting up the property, then on the ‘set {}’ handler, you can just add in the code to execute your event handler. However, as far as I know, there is no way to modify a built classes’ properties like that

@@IgnoreSolutions Exactly, setter of custom property can be changed but I am confused how to assign an event to a builtin class.

I didn’t I just don’t use it in the videos because its distracting

If there's a required property, set it via constructor so that all callers must also pass the new value(s). Not all callers require the same properties though, so they are good for setting optional values. Disagree with the idea of removing object initializers - they have their uses!

You can configure that in your IDE. C# itself doesn't care wherever you put the braces. You'll piss of other coders, but your program will compile fine. My biggest beef is with tabs. The IDE should match indentation, but let me control whatever whitespace I want after that. Still not a language thing, just VS' bloody formatter. At least you can set it to keep the opening { in the same line as the method declaration. I wish Roslyn had a plug-in mechanic for the formatter. 😮‍💨

@@phizc Yeah I just wish they would switch to OTBS by default.

@@privateparty4900 just making sure.. OTBS is One True Brace Style?

@@phizc Yeah. Obviously it's not the end of the world. It's just odd that C# adopts the best of everything... but is still wasting that line by default...

Why it should be dead? It's one of the most comfortable languages to write Desktop applications for Windows.

No I won’t. It complies with the Microsoft standard: github.com/dotnet/runtime/blob/main/docs/coding-guidelines/coding-style.md

If I recall correctly, underscore is not recommended for protected or public fields, but it is recommended for private fields. (I can't remember what the recommendation is for static fields.)