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.
@diego_samano
2 жыл бұрын
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); } }
@zoltanzorgo
2 жыл бұрын
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...
@nickchapsas
2 жыл бұрын
I didn’t talk about who originated the concept but rather showed what problem it tries to solve
@zoltanzorgo
2 жыл бұрын
@@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#.
@matthewwood4756
2 жыл бұрын
Delphi had properties since it’s inception (ie; V1). It was actually quite an advanced language.
@marcovtjev
2 жыл бұрын
@@matthewwood4756 It still is 🙂
@ncvjr
2 жыл бұрын
P.S. The "property init" is a syntax sugar only for design time. We can set value using reflection, normally.
@Tsunami14
2 жыл бұрын
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)
@noahyannis2465
2 жыл бұрын
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.
@hinekde
2 жыл бұрын
Nice, an evolution of Lists video would be cool, too. Seeing how Generics come in 2.0 and late different initializers, etc.
@damaomiX
2 жыл бұрын
Great summary, but since you mentioned record you should also mention record structs.
@ashutoshpattnaik5446
2 жыл бұрын
99.9k subs now... Road to f**ing 100k ... 🔥🔥
@vivekmahajan6888
2 жыл бұрын
Awesome work Nick
@sret919
2 жыл бұрын
Hi Nick, thanks for your quality videos. The lighting in your room looks beautiful.
@yunietpiloto4425
2 жыл бұрын
You gotta love these videos...nice work as always!
@IBITZEE
2 жыл бұрын
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...
@antonmartyniuk
2 жыл бұрын
Congratulations with 100K subscribers! Totally deserved it! Next target - 1M
@igorthelight
2 жыл бұрын
More realistically - next target would be 250k ;-)
@itsquick7250
2 жыл бұрын
Your cs concepts are amazing! keep it :)
@muczos
2 жыл бұрын
You are doing an icredible work :D I am really imprest. Greating from POLAND :)
@thecodeimplementation3417
11 ай бұрын
Fantastic!
@xavier.xiques
2 жыл бұрын
Another good video. Thanks Nick.
@Radictor44
2 жыл бұрын
nice one nick, really interesting
@aymansyria4303
2 жыл бұрын
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.
@marcovtjev
2 жыл бұрын
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-xizt
2 жыл бұрын
Good stuff mate! Keep em coming :-)
@harishraju4321
2 жыл бұрын
yo.....make one on exceptions or logging if you haven't already
@Alex-ou6ko
2 жыл бұрын
hey Nick, what do you think about a new course for c# source generators?
@binariti
2 жыл бұрын
I want a feature of auto-generated field being accessible in getter or setter without declaring it.
@Dayanto
2 жыл бұрын
Semi-auto properties using the "field" keyword seem to be coming in C# 11.
@BBdaCosta
2 жыл бұрын
Nice video, very interesting and funny
@ali_randomNumberHere
2 жыл бұрын
hey nick,thank you for great videos ,can you talk about threads/parallel/task deaply in your next videos?
@FSEAirboss
2 жыл бұрын
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.
@nickchapsas
2 жыл бұрын
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
@FSEAirboss
2 жыл бұрын
@@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.
@shakerlakes
2 жыл бұрын
@@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 :)
@shakerlakes
2 жыл бұрын
@@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
@kevindt100
2 жыл бұрын
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.
@kevindt100
2 жыл бұрын
@@dhkatz_ Thanks for explaning
@ckschumeister411
2 жыл бұрын
really interesting
@PanMaciek
2 жыл бұрын
I would love for c# to get delegated properties, this would be so nice for observables
@CXCubeHD
2 жыл бұрын
Properties are the greatest invention in programming language history * cough cough * Java
@myuuiii
2 жыл бұрын
❤️
@Mathius169
Жыл бұрын
Does anybody know any similar videos or course about Typescript and it’s evolution?
@billy65bob
2 жыл бұрын
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
@nickchapsas
2 жыл бұрын
There are cases where a library might have a usage limitation on fields only which means you can’t use it on properties directly.
@billy65bob
2 жыл бұрын
@@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.
@karthiksrivatsa8243
2 жыл бұрын
Waiting for DDD
@stevenbliss989
2 жыл бұрын
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.
@gorVerbinsky
2 жыл бұрын
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?
@phizc
2 жыл бұрын
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.
@gorVerbinsky
2 жыл бұрын
@@phizc sorry for misconfuse but I mean not throw exception; but not using ctor's with N-amount arguments.
@roelbrook7559
2 жыл бұрын
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.
@lollo4711
2 жыл бұрын
Just writing some VBA in Excel. To be easy I just declare PUBLIC vars (no PROPERTY). Why use Properties (when get/set is public) ?
@colinmaharaj
2 жыл бұрын
These came from Delphi. The creator of Delphi, created c#
@newbprofi
2 жыл бұрын
I am C++ warrior, i dont use properties, even in C#.
@moosaraza7584
2 жыл бұрын
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?
@IgnoreSolutions
2 жыл бұрын
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
@moosaraza7584
2 жыл бұрын
@@IgnoreSolutions Exactly, setter of custom property can be changed but I am confused how to assign an event to a builtin class.
@expertreviews1112
2 жыл бұрын
Readonly properties? With readonly keyword
@DeathRuNNerVST
2 жыл бұрын
hey Nick did you stop using copilot ??
@nickchapsas
2 жыл бұрын
I didn’t I just don’t use it in the videos because its distracting
@Denmaverick39
2 жыл бұрын
Evolution of dynamic type
@nickchapsas
2 жыл бұрын
I'd love to but it hasn't evolved that much actually since it was released
@Denmaverick39
2 жыл бұрын
@@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.
@thindal
2 жыл бұрын
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.
@buriedstpatrick2294
2 жыл бұрын
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.
@manseldavies915
2 жыл бұрын
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!
@privateparty4900
2 жыл бұрын
The one thing C# hasn't assimilated is OTBS. They incorporate everything else that's good; it's time guys. Make the switch.
@phizc
2 жыл бұрын
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. 😮💨
@privateparty4900
2 жыл бұрын
@@phizc Yeah I just wish they would switch to OTBS by default.
@phizc
2 жыл бұрын
@@privateparty4900 just making sure.. OTBS is One True Brace Style?
@privateparty4900
2 жыл бұрын
@@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...
@FabianD1991
2 жыл бұрын
No ha muerto C# aún?. Fuaa.
@igorthelight
2 жыл бұрын
Why it should be dead? It's one of the most comfortable languages to write Desktop applications for Windows.
@PeterBuchmann
2 жыл бұрын
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.
@nickchapsas
2 жыл бұрын
No I won’t. It complies with the Microsoft standard: github.com/dotnet/runtime/blob/main/docs/coding-guidelines/coding-style.md
@shakerlakes
2 жыл бұрын
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.)
Пікірлер: 84