P.S. The "property init" is a syntax sugar only for design time. We can set value using reflection, normally.
@diego_samano2 жыл бұрын
I think Pattern Matching sintax introduced on C#8 is a good option when you are comparing multiple values for the same property. At least it gives you different flavors to play around. So depending on the number of properties and nesting levels, you can have cleaner if statements. foreach (var user in users) { if (user.Birthday is { Year: 2022, Month: 03 }) { Console.WriteLine(user.Name); } if (user is { Birthday: { Year: 2022, Month: 03 } }) { Console.WriteLine(user.Name); } if (user is { Birthday.Year:2022, Birthday.Month: 03}) { Console.WriteLine(user.Name); } }
@zoltanzorgo2 жыл бұрын
C# property capabilities originate more from Delphi (Object Pascal) properties than from Java. The former had a modern property concept way before Java ever introduced one. No wonder: Anders Hejlsberg has his handmarks on both...
@nickchapsas2 жыл бұрын
I didn’t talk about who originated the concept but rather showed what problem it tries to solve
@zoltanzorgo2 жыл бұрын
@@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#.
@matthewwood47562 жыл бұрын
Delphi had properties since it’s inception (ie; V1). It was actually quite an advanced language.
@marcovtjev2 жыл бұрын
@@matthewwood4756 It still is 🙂
@diegoronkkomaki68582 жыл бұрын
Really appreciate these kind of videos. It is my opinion, that when you first start to learn a mature language and you run into a hard to understand subject, it really helps to study why the feature is like it is and how it has evolved. For example, lambdas and lambda syntax did not really make sense to me until I started reading about delegates and anonymous methods, basically understanding how it was done "in the early days" and how lambda syntax makes it so much better.
@noahyannis24652 жыл бұрын
Thanks for the video. I didn't know about the "is" and "not" key words. From now on, I'll use them more often, because I find them easier to read than != for example.
@Tsunami142 жыл бұрын
I've always been fascinated with seeing how languages evolve and the motivations / design goals behind then, so this is definitely right up my alley. I would love it if you did one on functional programming (e.eg delegates/events/callbacks -> anonymous functions/closures -> lambdas/LINQ)
@ashutoshpattnaik54462 жыл бұрын
99.9k subs now... Road to f**ing 100k ... 🔥🔥
@damaomiX2 жыл бұрын
Great summary, but since you mentioned record you should also mention record structs.
@hinekde2 жыл бұрын
Nice, an evolution of Lists video would be cool, too. Seeing how Generics come in 2.0 and late different initializers, etc.
@vivekmahajan68882 жыл бұрын
Awesome work Nick
@sret9192 жыл бұрын
Hi Nick, thanks for your quality videos. The lighting in your room looks beautiful.
@antonmartyniuk2 жыл бұрын
Congratulations with 100K subscribers! Totally deserved it! Next target - 1M
@igorthelight2 жыл бұрын
More realistically - next target would be 250k ;-)
@yunietpiloto44252 жыл бұрын
You gotta love these videos...nice work as always!
@muczos2 жыл бұрын
You are doing an icredible work :D I am really imprest. Greating from POLAND :)
@IBITZEE2 жыл бұрын
Very nice and instructive this historical perspectives... showing how and why something evolved... please do more of this,,, and I also would like to hear your opinion on what would be the next step in the topics evolution... or how it should evolve...
@itsquick72502 жыл бұрын
Your cs concepts are amazing! keep it :)
@thecodeimplementation341711 ай бұрын
Fantastic!
@xavier.xiques2 жыл бұрын
Another good video. Thanks Nick.
@binariti2 жыл бұрын
I want a feature of auto-generated field being accessible in getter or setter without declaring it.
@Dayanto2 жыл бұрын
Semi-auto properties using the "field" keyword seem to be coming in C# 11.
@aymansyria43032 жыл бұрын
Thank you, it's a good idea to make such videos, I left this language a long time ago and when I came back to it I found a lot of changes and new features which I'm not familiar with.
@Radictor442 жыл бұрын
nice one nick, really interesting
@marcovtjev2 жыл бұрын
Missed an analysis why these shorthands should be in language rather than some IDE macros that generate the boilerplate code. Is it really a good language principle to have as much syntax (and syntax variants) as possible to further some concept of terseness as ultimate goal? It is often implied that terseness saves time coding (but if it goes at the expense of readability and language orthogonality that is doubtful), but often many of the same goals can be achieved with some easily triggered autocompletion options in the IDE
@duznt-xizt2 жыл бұрын
Good stuff mate! Keep em coming :-)
@harishraju43212 жыл бұрын
yo.....make one on exceptions or logging if you haven't already
@PanMaciek2 жыл бұрын
I would love for c# to get delegated properties, this would be so nice for observables
@FSEAirboss2 жыл бұрын
So just wondering, what is an actual use case for [field: obsolete] on a compiler generated hidden field? I can see one for a custom backing field, but wouldn't [obsolete] be used in that case? Thanks for these, interesting topics.
@nickchapsas2 жыл бұрын
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
@FSEAirboss2 жыл бұрын
@@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.
@shakerlakes2 жыл бұрын
@@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.
@dhkatz_2 жыл бұрын
@@shakerlakes You think so but in C# 11 we're finally getting access to those hidden backing fields through the 'field' keyword :)
@shakerlakes2 жыл бұрын
@@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
@kevindt1002 жыл бұрын
Still waiting on the field keyword. Semi-Auto properties are going to be great for WPF. Still sad that it got delayed to C# 11
@R.B.2 жыл бұрын
Is that to expand on records?
@dhkatz_2 жыл бұрын
@@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; } = "";
@R.B.2 жыл бұрын
@@dhkatz_ oh yeah. I do remember that being discussed in one of the talks.
@kevindt1002 жыл бұрын
@@dhkatz_ Thanks for explaning
@BBdaCosta2 жыл бұрын
Nice video, very interesting and funny
@Alex-ou6ko2 жыл бұрын
hey Nick, what do you think about a new course for c# source generators?
@ali_randomNumberHere2 жыл бұрын
hey nick,thank you for great videos ,can you talk about threads/parallel/task deaply in your next videos?
@ckschumeister4112 жыл бұрын
really interesting
@CXCubeHD2 жыл бұрын
Properties are the greatest invention in programming language history * cough cough * Java
@Mathius169 Жыл бұрын
Does anybody know any similar videos or course about Typescript and it’s evolution?
@myuuiii2 жыл бұрын
❤️
@billy65bob2 жыл бұрын
a field:Obsolete attribute for the backing field... why would you even do that? What purpose does this serve? How would you even use it since the compiler won't let you use the autogenerated backing field directly
@nickchapsas2 жыл бұрын
There are cases where a library might have a usage limitation on fields only which means you can’t use it on properties directly.
@billy65bob2 жыл бұрын
@@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.
@karthiksrivatsa82432 жыл бұрын
Waiting for DDD
@gorVerbinsky2 жыл бұрын
Hi Nick, I tried this approach to create readonly properties but .Net5 DI doesn't pass anything to them. In example: public IContactsProcessService _сontactProcessService { get; init; }. Is there way throw long Ctor's and use this smart properties?
@phizc2 жыл бұрын
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.
@gorVerbinsky2 жыл бұрын
@@phizc sorry for misconfuse but I mean not throw exception; but not using ctor's with N-amount arguments.
@stevenbliss9892 жыл бұрын
I love your videos, learning a lot about C#, but sadly at every video I say to myself about C# ...so messy! Crazy considering the C# creator knows better from his previous language, Delphi.
@lollo47112 жыл бұрын
Just writing some VBA in Excel. To be easy I just declare PUBLIC vars (no PROPERTY). Why use Properties (when get/set is public) ?
@colinmaharaj2 жыл бұрын
These came from Delphi. The creator of Delphi, created c#
@roelbrook75592 жыл бұрын
I was hoping when C# 10 came up, you'd start with semi-auto-properties. But, after re-googling it, it seems this has been stashed for C# 11... Unfortunately.
@expertreviews11122 жыл бұрын
Readonly properties? With readonly keyword
@newbprofi2 жыл бұрын
I am C++ warrior, i dont use properties, even in C#.
@Denmaverick392 жыл бұрын
Evolution of dynamic type
@nickchapsas2 жыл бұрын
I'd love to but it hasn't evolved that much actually since it was released
@Denmaverick392 жыл бұрын
@@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.
@moosaraza75842 жыл бұрын
Hey Nick! I would like to ask can we bind an event handler to a property? Like suppose we have System.Diagnostics.Process and whenever the Process.HasExited property is changed I want to fire an event/delegate. Can we do that? Or can we add delegate to a property of our own class?
@IgnoreSolutions2 жыл бұрын
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
@moosaraza75842 жыл бұрын
@@IgnoreSolutions Exactly, setter of custom property can be changed but I am confused how to assign an event to a builtin class.
@DeathRuNNerVST2 жыл бұрын
hey Nick did you stop using copilot ??
@nickchapsas2 жыл бұрын
I didn’t I just don’t use it in the videos because its distracting
@thindal2 жыл бұрын
Too bad that init doesn't work in .net framework. Sure, it's EOL since loooong ago, but it'd still be nice to have.
@buriedstpatrick22942 жыл бұрын
I've always hated the object initializer approach, because if you add a property to a class it might not have been initialized in all the code that's using it. So I always go for constructors or, even better, records. As you explained, with records you get all the immutability you need to write good robust code and still get the benefits of serialization. It's a shame you can't use records on older projects, because I hate having to define all my properties as nullable which then leads me to have to write a bunch of null-checks in my business logic. I kind of want object initialization to just be taken out of the language, but that's probably never going to happen. But if you're on the latest version of .NET there's really no reason to write code like that.
@manseldavies9152 жыл бұрын
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!
@privateparty49002 жыл бұрын
The one thing C# hasn't assimilated is OTBS. They incorporate everything else that's good; it's time guys. Make the switch.
@phizc2 жыл бұрын
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. 😮💨
@privateparty49002 жыл бұрын
@@phizc Yeah I just wish they would switch to OTBS by default.
@phizc2 жыл бұрын
@@privateparty4900 just making sure.. OTBS is One True Brace Style?
@privateparty49002 жыл бұрын
@@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...
@FabianD19912 жыл бұрын
No ha muerto C# aún?. Fuaa.
@igorthelight2 жыл бұрын
Why it should be dead? It's one of the most comfortable languages to write Desktop applications for Windows.
@PeterBuchmann2 жыл бұрын
Nick, could you please stop using field names starting with underscores. This does not comply with the C# style according to stylecop, which could also be a good theme for a video.
@nickchapsas2 жыл бұрын
No I won’t. It complies with the Microsoft standard: github.com/dotnet/runtime/blob/main/docs/coding-guidelines/coding-style.md
@shakerlakes2 жыл бұрын
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.)