Thanks for answering my question Tim. I noticed that you are going through all of the comments with questions and addressing them. Thanks for your hard work and dedication. Keep up the good work producing content that is approachable, even pleasant, to view. It often feels like I'm on a call with an old friend reminding me of something that I forgot. :)
I gotta be honest. With both C# and .Net, I kind of feel like a lot of effort is going into solving problems that I never had. I still have to learn all the new ways, so that I can recognize and understand them when I see them. But given that copilot will type my boilerplate for me anyway, I don't see much advantage in saving 3 lines of code. Also, OCD me might actually have to go back and chance all my DI to the new way, just so my code doesn't mock me in my sleep.
That may be true to an extent. The problems that are solved in C# and .NET updates aren't necessarily problems that you personally have experienced. It is a broad ecosystem with lots of users at different levels with different use-cases.
New to the channel and also a new .net developer. The comment section is valuable to me as I read the interactions between what the other senior developers concerns are and your comments. Thank you for being candid on your responses.
That was very instructive. I've noticed it a couple of days ago when I finally decide to upgrade a blazor app from 7 to 8. This video comes just in time, thank you Tim.
Great explanation Tim, I liked the conclusion you provided "if it make code more readable the go for Primary Constructors if not then don't..." I beleive that pretty much explain how to use this feature.
@@IAmTimCorey Yes. Why it would be "problem" for a developer to have the first class? Its just a model, you gonna spend most of the time on logic not on models. In any case my opinion is that the 2nd version is confusing.
Neither is a problem. The question, though, is going to be which one is more readable. Code is meant to be read by humans. If your team feels that the first is more readable than the second, absolutely do that one. As for the specific code example, this is just a demo piece of code. It would actually be more likely to be a class that uses dependency injection.
When using primary constructors with DI, in this example, how can we log the time the object is created? Seems we can't. No constructor. I thought you would mention something to the effect, or have I misunderstood the concept or missed a trick to do this? If we do, some error-prone boilerplate code starts creeping in again. I have to say, I don't think I'm a fan of this. I often update UI-bound labels with information passed by a service when the ViewModel is constructed, and all benefits are lost. PS: You are my go-to channel for C#, Thanks!
You can have a constructor with a primary constructor as well, but if it is starting to get complicated then your class probably isn't a good use case for primary constructors. Personally, I have a LOT of classes that just take in dependencies and don't do anything else in the constructor. Those are good use cases.
I think I see your point on why this is cleaner and how you can enforce the readonly in the DI example. I honestly don’t think either way of constructors is better than the other, really just comes down to preference at the end of the day.
Good to know. Just something to think about, though: there isn't really a difference between passing dependencies into a constructor and then saving them as readonly fields vs passing dependencies into a primary constructor and saving them as readonly fields.
@@IAmTimCorey of course, if next version introduces read-only support directly into PC, that would be really useful to make the ctor compact and consice since we don't have fields on the class body anymore
Seems a bit of a pointless feature that will probably lead to more readability issues when some one else comes to fix a bug or add a feature in the future. When most devs probably create and instantiate class levels fields from the constructor parameters with the existing short cuts then what is this saving?
For me the DI assign field thing doesn't solve it yet because it generates it without the underscore. It may seem silly but when doing that kind of boilerplate stuff i look for speed, and if the suggestion is wrong and I have to manually put the underscore then it doesn't work for me. Great vid still, trying to showcase most of the use cases.
I was wondering, instead of removing your underscore from the field declaration. Would it not be a better pattern to add the underscore to the constructor parameter?
@@IAmTimCorey a standard based on non primary constructors, right? I don't know, it feels like I can agree to such a pattern change in the future... 🤔 But I certainly don't feel strongly about it 😅
Yeah, that's the question, right? Does the standard change because of the primary constructor or does the primary constructor change to fit the standard. I think the standard needs to stay, because it isn't just for constructors, it is for all methods. All methods use camelCase parameters. So we either start using that same naming structure for the readonly fields, or we figure out something else. In Blazor, we already have this issue when it comes to injecting services. We inject them typically as either camelCase or PascalCase, but they become fields for us to use (I don't believe they are readonly, though).
Thank you, I just want to point out that many of the improvements #Microsoft do on C# in merely syntactic sugar, but the question is does it add any value in performance or validation?
Not in terms of application performance. The performance it adds is in terms of readability and simplicity of your code (code is meant to be read by humans).
As a newbie, I think a primary constructor is a more naturally-understood way to start a class. The .NET7 style constructor was something that took me ages to grasp, as 1) I hadn't understood it's purpose- this is because I hadn't yet separated the concepts of instantiation and declaration of an object. 2) The mental overhead of things to remember for "just starting a class". The .NET7 ctor is verbose - it appears that the same variable and class name x2, and having the subtlety of parameter vs property, but also with specific arbitrary syntax conventions for these objects (i.e. caps, no caps, leading underscore). If you want to get to the "do something" part of the code, I think the primary constructor will mosty apply to get you there, with the config options on the .NET7 style ctor being something to learn in the next lesson :)
We'll have to disagree on this one. To me the old style looks clearer. You see that you're dealing with constructor parameters and private fields and it's clear from the code what the life scope of everything is. In the new syntax you NEED to know that those will be available the same like the private fields are. You need to be aware that using the same name for private fields and primary constructor parameters is changing the way the code works. Of course, you can assume that the scope for the new style parameters is the whole instance, but it's not 100% clear what the purpose is. For instance, you can't infer from the code if the values are read only, or not, or if they get altered in any method call in the class, are the new values reflected in the calling code? You can't say these things, unless you read the documentation, while in the old way, it is clear what everything is. If you know the basics of how scopes are defined by {} you know what's available where. You don't need to read any documentation for that. Plus, making a class looking like a method looks ugly to me. The class definition now looks like a method definition. Imagine if your class is a base class with a primary constructor and the derived class also implements some interfaces. The whole syntax will look more complex. Choice is good, but in this case, I think, this is a solution to a problem we didn't have.
This probably help class creation efficiency for simple classes that are nice and tidy. Wouldn't it have been much cleaner to just allow a readonly on the primary ctor parameters directly? Seems like 2 steps forward and one step back for clarity.
Something like (readonly string firstname) ?, well could be, but they need to keep something for upcoming versions ;-) Right now the rule is consistent with any automatic properties; it's read/write, unless otherwise noted.
Adding readonly in the parameter line is a new syntax addition. There isn’t another place that does that. Doing so raises some issues like how read only should it be? Can it be mutated in the constructor or not? These are the things that need to be figured out.
I'm curious how, or if it is possible, to use the base keyword with a primary constructor. A common example would be implementing a DbContext in entity framework.
You would do it like so: public class Test(string data, int count) : ControllerBase or, if ControllerBase had a primary constructor, it would be something like: public class Test(string data, int count) : ControllerBase(data)
Maybe not completely related but I am trying to figure out a distinction between using a property without a setter and one with an init. Is there any and if so, what is the difference? var myclass = new MySample("test", "test2"); myclass._prop1 = "blabla"; // Is not allowed myclass._prop2 = "whatever"; // Is not allowed class MySample { public string _prop1 { get; } public string _prop2 { get; init; } public MySample(string prop1, string prop2) { _prop1 = prop1; _prop2 = prop2; } public void PropTest() { _prop1 = "blabla"; // Is not allowed _prop2 = "whatever"; // Is not allowed } }
Honestly, those primary constructors and records seem a little too much for me. I get the idea, but it basically obfuscates something that has been obvious for years and pretty standard for every language.
I'm not sure what it is obfuscating. Here is an example. What is hidden here: public class PersonModel { private readonly string firstName; private readonly string lastName; public PersonModel(string firstName, string lastName) { this.firstName = firstName; this.lastName = lastName; } } compared to: public class PersonModel (string firstName, string lastName) { private readonly string firstName = firstName; private readonly string lastName = lastName; }
@@IAmTimCorey thats not exactly the case you show. You had a class SImpleAfter, like so: public class SimpleAfter(string firstName, string lastName) { public string FullName() { return firstName + lastName; } } Now, I know this FullName() is a simple method, but imagine something longer and more complicated than that. Those "firstName" and "lastName" in that method look like local parameters, but in fact they are class fields. Thats a bit weird and I find that confusing. Maybe it's just me, but I prefer to write a couple more lines of code, but at the same time maintain code readability. Still, thanks for explaining the subject. Huge fan ;)
It's a good idea, but without the ability to add readonly keyword to a parameter it's not that great in practice. As for the workaround of reassigning to field, I'd want to keep the _logger syntax, so I'd rather rename the primary constructor parameter to _logger as well.
If you have checks over parameters constraints... I don't see a (clean) way to maintain them. For example if in the constructor you have ``Guard.InTotEmptyOrWhiteSpace(firstName)`` or Guard.IsGreaterThan(age, 16 .)`` .
If you have constraints that you apply in the constructor, then you would use the constructor. The Primary Constructor would be for if you are only using the constructor for dependency injection.
Dont like it, the function prototype is not differentiated from a standard constructor, and its obfuscating data and what is going on which makes it a pit fall for beginner and intermediate programmers
You don’t have to use it. As for obfuscating data, I don’t really see that as a stumbling block. You see the variables. What you don’t see is the underlying field that is required for them to work, but you do t even need to know that exists. As for it not being any different than a standard constructor, it cuts down on a lot of repetitive code.
It reduces lines of code without reducing understanding. How is that not better? Yes, at first it will look strange, but that's part of the evolution of a language.
@@IAmTimCorey I strongly agree programming languages are impossible to design perfectly the first time and must evolve. They should, however, improve without reducing clarity or introducing complexity. C# has many welcomed new features such as string interpolation. It reduces pages of string manipulation code into a few lines with no impact on size or performance. It makes your code safer since string manipulation and conversion code is often error prone. It makes your code far more readable and maintainable by placing all the variable substitutions in situ. It's also ridiculously simple to learn and use. Few will argue that it's one of the best features added to C#. The new primary constructor, on the other hand, took you an entire video to explain, yet its benefits are still vague. It breaks the object-oriented notational convention of WYSIWIT (What You See Is What Is There). Parameters are scoped to methods and constructors bodies and declared inside their respective signatures. Member variables are scoped to the class and declared inside the body of the class. It is braindead easy to differentiate parameters and member variables visually and cognitively, whereas the primary constructor distorts and fuzzes the two. That's awesome for rock and roll, but not for code. This new "feature" brings with it new implications to contend with for questionable benefits.
The reason I took a whole video to explain them is to ensure people had a good grasp on the depth of the topic. This is an example of senior developer coding. A junior developer writes simple code to solve simple problems. A mid-level developer writes complex code to solve complex problems. A senior developer writes simple code to solve complex problems. Just because the code is simple doesn't mean it doesn't work in a complex manner. As for the benefits, here is a simple example that includes making the parameters readonly: public class PersonModel { private readonly string firstName; private readonly string lastName; public PersonModel(string firstName, string lastName) { this.firstName = firstName; this.lastName = lastName; } } compared to: public class PersonModel (string firstName, string lastName) { private readonly string firstName = firstName; private readonly string lastName = lastName; }
I don’t love some of the problems this creates. Relying on developers to do the work of managing if instance variables/fields are mutable in this way seems more prone to mistakes. I can appreciate the reduction in verbosity, but I’m not certain it will outweigh the potential risks
How are we not already relying on developers to manage if something is mutable? If it comes in via a normal constructor, it is mutable. It is up to the developer to save it as readonly. The same is true with this new system.
@@IAmTimCorey You make a fair point. I guess what I really meant is that we have to manage seperate names and whether we assign a value to a property etc. You're right that either way it falls to the developer, though.
Hi Tim, Honestly? What's the point? If I use constructors to want or need to do additional initializations, I can't use this notation. Maybe with other classes. Then we have code again that was created one way or another. What a load of garbage. This has nothing to do with older or anyone else not wanting to do it this way, it makes absolutely no sense to me. Yet another point where Microsoft continues to break C#. Instead of keeping it clean, simple and standardized, Microsoft is doing exactly the opposite. Not good, not good at all. Sorry, but again I can't share your euphoria.
First, you absolutely can use this with other constructors. Second, the most common constructor is one that just takes in dependencies from dependency injection. Third, this is cleaner and simpler for a lot of cases (including those where you are using dependency injection). But most importantly, you aren't required to use it. That's the beauty of it. If you want to use the "regular" mechanisms, you can.
@@IAmTimCorey Tim, why doesn't anyone use the goto function anymore? It's there, I can use it when and if I want! But why doesn't anyone use it? The problem is not whether I can use it or not. The problem is that one person wants to use it and uses it, and the other doesn't (fortunately, no longer in the case of "Goto"). It also has nothing to do with being open to change. It has to do with leaving straightforward structures. The mere fact that you can't use this spelling in all cases should be a red flag. I can't decide whether to always use it or not. This gives the code a bit more complexity and makes it harder to read because a different form is always chosen. For the idea of clean code, this approach is very questionable in my eyes. You are and remain one of the best C# developers in my eyes. But if I could wish for something, it would be that you would question innovations a little more critically and not always celebrate them immediately. I don't know if you celebrate Christmas, but I hope you do and I won't offend you if I wish you and your family a wonderful Christmas. Have a great Christmas and stay healthy, and have a wonderful and successful 2024 Thanks for your Content
Gotta say I'm not a big fan of this feature yet. I think it needs a bit more work and then it might be a great change. While it is nice that the code is more compact and somewhat more clean, I don't like that it leaves all the parameters alive forever in the class even if you assign them. And it kind of messes up the standard naming convention of _name being a private field, since it wants the exact same same.
The parameters don't live on if you overwrite them like so: public class Test (string connectionString) { private readonly string connectionString = connectionString; ... However, if you couple that with wanting to use the underscore but not wanting to use the underscore in the primary constructor, that's when you have the issue. And yeah, I understand that.
The entire implementation of primary constructors is off IMO. The biggest benefit of primary constructors in my opinion are quickly indicating the things that are necessary. They seem to have simply copy pasted the record functionality for primary constructors. They really needed to make it work with readonly services being inected, because as it stands now IMO it's something you're better off not using at all.
To push back a bit, we don't have that now. The services passed into regular constructors can be mutated. It is up to us to save them to readonly fields. Isn't that the same as what we have here?
@@IAmTimCorey why not just use readonly fields? A record is a fairly new type so it could make sense there. It seems to solve a problem that we didn't have. In general that leads to complexity.
You can use readonly fields with this. The difference is how many lines of code it takes to assign the readonly fields. For example: public class PersonModel { private readonly string firstName; private readonly string lastName; public PersonModel(string firstName, string lastName) { this.firstName = firstName; this.lastName = lastName; } } compared to: public class PersonModel (string firstName, string lastName) { private readonly string firstName = firstName; private readonly string lastName = lastName; }
They are working on making C# simpler and less verbose. C# has been known as a wordy language without really needing to be. The same is true for constructors. Check out this comparison: public class PersonModel { private readonly string firstName; private readonly string lastName; public PersonModel(string firstName, string lastName) { this.firstName = firstName; this.lastName = lastName; } } compared to: public class PersonModel (string firstName, string lastName) { private readonly string firstName = firstName; private readonly string lastName = lastName; } Both do the same thing. One is just a LOT cleaner. This has been a highly requested feature. It is also something that allows for other things they want to do in the future. Think of these changes like dominos in a chain rather than individual features.
As always, new people will get used to it, older people don't want to change, until in 10 years from now you won't find code in the "old"/current style anymore.
@@holger_p I do not think it is wanting to change or not, question does it adds any value. With so many options doing the same thing, new syntactic sugar sometimes seems arguably unnecessary/confusing.
@@0i0l0o The new value is less typing. Around 1995 we had the same discussion on "I get along with Fax - I don't need email - it's confusing (to learn something new)". You might be right, it's too many options, but to be backward compatible, they cannot strike out the old options. If you want less options: Don't use the old ones any more ;-) I think the habit of creating more classes has changed, so if you want to create 5 classes in 10 minutes, you need better features.
@@holger_p Please don't say, "Older people don't want to change"; it is ridiculous. Primary constructors are, at best, a tiny subset of constructors. They are more similar to required properties than constructors. You can not replace constructors with primary constructors, so it is not a matter of backward compatibility. They are different features. I like the syntax, but it is a shame we will get more bugs due to the issues with mutability. What C# needs is something along the lines of discriminated unions.
Thanks for answering my question Tim. I noticed that you are going through all of the comments with questions and addressing them. Thanks for your hard work and dedication. Keep up the good work producing content that is approachable, even pleasant, to view. It often feels like I'm on a call with an old friend reminding me of something that I forgot. :)
You are welcome.
I gotta be honest. With both C# and .Net, I kind of feel like a lot of effort is going into solving problems that I never had.
I still have to learn all the new ways, so that I can recognize and understand them when I see them. But given that copilot will type my boilerplate for me anyway, I don't see much advantage in saving 3 lines of code.
Also, OCD me might actually have to go back and chance all my DI to the new way, just so my code doesn't mock me in my sleep.
That may be true to an extent. The problems that are solved in C# and .NET updates aren't necessarily problems that you personally have experienced. It is a broad ecosystem with lots of users at different levels with different use-cases.
@@luke5100 Then maybe that controller needs to be refactored. Controllers need to be simple. And the Ctrl. does most of the typing for you.
New to the channel and also a new .net developer. The comment section is valuable to me as I read the interactions between what the other senior developers concerns are and your comments. Thank you for being candid on your responses.
You are welcome.
That was very instructive. I've noticed it a couple of days ago when I finally decide to upgrade a blazor app from 7 to 8. This video comes just in time, thank you Tim.
I am glad it was helpful.
Same here (: Thanks Tim !
Great explanation Tim, I liked the conclusion you provided "if it make code more readable the go for Primary Constructors if not then don't..." I beleive that pretty much explain how to use this feature.
Thanks!
It doesn't make code more readably in any case. It make it harder and more confusing. For me is no.
You are saying this is easier to read?
public class PersonModel
{
private readonly string firstName;
private readonly string lastName;
public PersonModel(string firstName, string lastName)
{
this.firstName = firstName;
this.lastName = lastName;
}
}
compared to:
public class PersonModel (string firstName, string lastName)
{
private readonly string firstName = firstName;
private readonly string lastName = lastName;
}
@@IAmTimCorey Yes. Why it would be "problem" for a developer to have the first class? Its just a model, you gonna spend most of the time on logic not on models. In any case my opinion is that the 2nd version is confusing.
Neither is a problem. The question, though, is going to be which one is more readable. Code is meant to be read by humans. If your team feels that the first is more readable than the second, absolutely do that one. As for the specific code example, this is just a demo piece of code. It would actually be more likely to be a class that uses dependency injection.
When using primary constructors with DI, in this example, how can we log the time the object is created? Seems we can't. No constructor. I thought you would mention something to the effect, or have I misunderstood the concept or missed a trick to do this?
If we do, some error-prone boilerplate code starts creeping in again. I have to say, I don't think I'm a fan of this.
I often update UI-bound labels with information passed by a service when the ViewModel is constructed, and all benefits are lost.
PS: You are my go-to channel for C#, Thanks!
You can have a constructor with a primary constructor as well, but if it is starting to get complicated then your class probably isn't a good use case for primary constructors. Personally, I have a LOT of classes that just take in dependencies and don't do anything else in the constructor. Those are good use cases.
Thanks
Thank you!
I think I see your point on why this is cleaner and how you can enforce the readonly in the DI example. I honestly don’t think either way of constructors is better than the other, really just comes down to preference at the end of the day.
That can be true, yes. I think for me, I would change preference to "what is more readable", but that's my opinion.
I was waiting for this one from you. Sometimes I'm too busy to look out new features.Thanks
You are welcome.
I love this Syntex but currently I have plan to not use it until next version of c# that would probably introduce read-only support
Good to know. Just something to think about, though: there isn't really a difference between passing dependencies into a constructor and then saving them as readonly fields vs passing dependencies into a primary constructor and saving them as readonly fields.
@@IAmTimCorey of course, if next version introduces read-only support directly into PC, that would be really useful to make the ctor compact and consice since we don't have fields on the class body anymore
Seems a bit of a pointless feature that will probably lead to more readability issues when some one else comes to fix a bug or add a feature in the future. When most devs probably create and instantiate class levels fields from the constructor parameters with the existing short cuts then what is this saving?
It isn't about writing the code, it is about reading the code. Code is written once and read dozens of times.
Very very nice! Thanks so much for such a great explanation!
You are welcome.
What is the behavior if you were to mark the class as partial? I'll need to try this to see.
For me the DI assign field thing doesn't solve it yet because it generates it without the underscore. It may seem silly but when doing that kind of boilerplate stuff i look for speed, and if the suggestion is wrong and I have to manually put the underscore then it doesn't work for me. Great vid still, trying to showcase most of the use cases.
That’s an editor change you can make - you can configure it to include the underscore.
Sir, your explanation has greatly clarified things. Thank you.
You are welcome.
Nice and detailed explanation with recommendations. thx
You are welcome.
I was wondering, instead of removing your underscore from the field declaration. Would it not be a better pattern to add the underscore to the constructor parameter?
That would violate the standard naming for parameters, so I would like to avoid that.
@@IAmTimCorey a standard based on non primary constructors, right? I don't know, it feels like I can agree to such a pattern change in the future... 🤔 But I certainly don't feel strongly about it 😅
Yeah, that's the question, right? Does the standard change because of the primary constructor or does the primary constructor change to fit the standard. I think the standard needs to stay, because it isn't just for constructors, it is for all methods. All methods use camelCase parameters. So we either start using that same naming structure for the readonly fields, or we figure out something else. In Blazor, we already have this issue when it comes to injecting services. We inject them typically as either camelCase or PascalCase, but they become fields for us to use (I don't believe they are readonly, though).
Thank you, I just want to point out that many of the improvements #Microsoft do on C# in merely syntactic sugar, but the question is does it add any value in performance or validation?
Not in terms of application performance. The performance it adds is in terms of readability and simplicity of your code (code is meant to be read by humans).
Love this syntax especially in di situations, minimizes repeated code.
Yeah, I think it will be really useful in some spots.
As a newbie, I think a primary constructor is a more naturally-understood way to start a class.
The .NET7 style constructor was something that took me ages to grasp, as
1) I hadn't understood it's purpose- this is because I hadn't yet separated the concepts of instantiation and declaration of an object.
2) The mental overhead of things to remember for "just starting a class". The .NET7 ctor is verbose - it appears that the same variable and class name x2, and having the subtlety of parameter vs property, but also with specific arbitrary syntax conventions for these objects (i.e. caps, no caps, leading underscore).
If you want to get to the "do something" part of the code, I think the primary constructor will mosty apply to get you there, with the config options on the .NET7 style ctor being something to learn in the next lesson :)
Thanks for sharing!
We'll have to disagree on this one. To me the old style looks clearer. You see that you're dealing with constructor parameters and private fields and it's clear from the code what the life scope of everything is. In the new syntax you NEED to know that those will be available the same like the private fields are. You need to be aware that using the same name for private fields and primary constructor parameters is changing the way the code works. Of course, you can assume that the scope for the new style parameters is the whole instance, but it's not 100% clear what the purpose is. For instance, you can't infer from the code if the values are read only, or not, or if they get altered in any method call in the class, are the new values reflected in the calling code? You can't say these things, unless you read the documentation, while in the old way, it is clear what everything is. If you know the basics of how scopes are defined by {} you know what's available where. You don't need to read any documentation for that.
Plus, making a class looking like a method looks ugly to me. The class definition now looks like a method definition. Imagine if your class is a base class with a primary constructor and the derived class also implements some interfaces. The whole syntax will look more complex.
Choice is good, but in this case, I think, this is a solution to a problem we didn't have.
As a JavaScript main, i welcome this C# change!
Great!
what is the name of the extension to colorize the brackets and parentheses?
This is built into Visual Studio. Check out this video on enabling them: th-cam.com/video/O1GUbjacjKQ/w-d-xo.htmlsi=dSn2fOm0Gyx27yGY
This probably help class creation efficiency for simple classes that are nice and tidy. Wouldn't it have been much cleaner to just allow a readonly on the primary ctor parameters directly? Seems like 2 steps forward and one step back for clarity.
Something like (readonly string firstname) ?, well could be, but they need to keep something for upcoming versions ;-)
Right now the rule is consistent with any automatic properties; it's read/write, unless otherwise noted.
Adding readonly in the parameter line is a new syntax addition. There isn’t another place that does that. Doing so raises some issues like how read only should it be? Can it be mutated in the constructor or not? These are the things that need to be figured out.
I'm curious how, or if it is possible, to use the base keyword with a primary constructor. A common example would be implementing a DbContext in entity framework.
You would do it like so:
public class Test(string data, int count) : ControllerBase
or, if ControllerBase had a primary constructor, it would be something like:
public class Test(string data, int count) : ControllerBase(data)
@@IAmTimCorey Thanks, I was going to ask the same thing. This answers my question. You should update your video to include this :D
Tim, on the bottom left side of the editor, to the right of the Copilot icon, there is a purple icon that allows you to turn off suggestions.
Yep, thanks, I should have used that one.
Hey Tim. How do I get the same intellisence highlighting colors as you? Dark mode in VS 2022 Community is different than yours.
I'm using Visual Studio 2022 Community Edition with Dark mode. I don't think there is anything else affecting it.
Maybe not completely related but I am trying to figure out a distinction between using a property without a setter and one with an init. Is there any and if so, what is the difference?
var myclass = new MySample("test", "test2");
myclass._prop1 = "blabla"; // Is not allowed
myclass._prop2 = "whatever"; // Is not allowed
class MySample
{
public string _prop1 { get; }
public string _prop2 { get; init; }
public MySample(string prop1, string prop2)
{
_prop1 = prop1;
_prop2 = prop2;
}
public void PropTest()
{
_prop1 = "blabla"; // Is not allowed
_prop2 = "whatever"; // Is not allowed
}
}
Great video as always - Don't know about this language feature though...
It has its uses.
@@IAmTimCorey I think it'd be better if it made the passed in variables readonly by default
Absolutely, and that is being worked on for .NET 9 (November, 2024).
thank you for this tim
You are welcome.
I definitely see a usage for it, especially in combination with DI. Makes it a lot cleaner and more readable.👍
Great!
Can you do an updated video of downloading a binary file in Blazor server for .net 8, please?
Do you have a video on azure data factory?
Not yet.
Primary Constructors are actually available in C# 11, as long as you set language version to preview.
Correct. Since it is technically a compiler feature, you can use it in certain previous versions.
Honestly, those primary constructors and records seem a little too much for me. I get the idea, but it basically obfuscates something that has been obvious for years and pretty standard for every language.
I'm not sure what it is obfuscating. Here is an example. What is hidden here:
public class PersonModel
{
private readonly string firstName;
private readonly string lastName;
public PersonModel(string firstName, string lastName)
{
this.firstName = firstName;
this.lastName = lastName;
}
}
compared to:
public class PersonModel (string firstName, string lastName)
{
private readonly string firstName = firstName;
private readonly string lastName = lastName;
}
@@IAmTimCorey thats not exactly the case you show.
You had a class SImpleAfter, like so:
public class SimpleAfter(string firstName, string lastName)
{
public string FullName()
{
return firstName + lastName;
}
}
Now, I know this FullName() is a simple method, but imagine something longer and more complicated than that. Those "firstName" and "lastName" in that method look like local parameters, but in fact they are class fields. Thats a bit weird and I find that confusing. Maybe it's just me, but I prefer to write a couple more lines of code, but at the same time maintain code readability.
Still, thanks for explaining the subject. Huge fan ;)
It's a good idea, but without the ability to add readonly keyword to a parameter it's not that great in practice. As for the workaround of reassigning to field, I'd want to keep the _logger syntax, so I'd rather rename the primary constructor parameter to _logger as well.
You can make it readonly with just one additional line. I don’t think that is a big deal for a year.
If you have checks over parameters constraints... I don't see a (clean) way to maintain them.
For example if in the constructor you have ``Guard.InTotEmptyOrWhiteSpace(firstName)`` or Guard.IsGreaterThan(age, 16 .)`` .
If you have constraints that you apply in the constructor, then you would use the constructor. The Primary Constructor would be for if you are only using the constructor for dependency injection.
him: advertizes something, opens visual studio, clicks something with mouse just to create 1 file.....
me: gets bored, closes the video
Dont like it, the function prototype is not differentiated from a standard constructor, and its obfuscating data and what is going on which makes it a pit fall for beginner and intermediate programmers
You don’t have to use it. As for obfuscating data, I don’t really see that as a stumbling block. You see the variables. What you don’t see is the underlying field that is required for them to work, but you do t even need to know that exists. As for it not being any different than a standard constructor, it cuts down on a lot of repetitive code.
These new "features" are not making C# any safer, nor easier to work with.
It reduces lines of code without reducing understanding. How is that not better? Yes, at first it will look strange, but that's part of the evolution of a language.
@@IAmTimCorey I strongly agree programming languages are impossible to design perfectly the first time and must evolve. They should, however, improve without reducing clarity or introducing complexity. C# has many welcomed new features such as string interpolation. It reduces pages of string manipulation code into a few lines with no impact on size or performance. It makes your code safer since string manipulation and conversion code is often error prone. It makes your code far more readable and maintainable by placing all the variable substitutions in situ. It's also ridiculously simple to learn and use. Few will argue that it's one of the best features added to C#.
The new primary constructor, on the other hand, took you an entire video to explain, yet its benefits are still vague. It breaks the object-oriented notational convention of WYSIWIT (What You See Is What Is There). Parameters are scoped to methods and constructors bodies and declared inside their respective signatures. Member variables are scoped to the class and declared inside the body of the class. It is braindead easy to differentiate parameters and member variables visually and cognitively, whereas the primary constructor distorts and fuzzes the two. That's awesome for rock and roll, but not for code. This new "feature" brings with it new implications to contend with for questionable benefits.
The reason I took a whole video to explain them is to ensure people had a good grasp on the depth of the topic. This is an example of senior developer coding. A junior developer writes simple code to solve simple problems. A mid-level developer writes complex code to solve complex problems. A senior developer writes simple code to solve complex problems. Just because the code is simple doesn't mean it doesn't work in a complex manner. As for the benefits, here is a simple example that includes making the parameters readonly:
public class PersonModel
{
private readonly string firstName;
private readonly string lastName;
public PersonModel(string firstName, string lastName)
{
this.firstName = firstName;
this.lastName = lastName;
}
}
compared to:
public class PersonModel (string firstName, string lastName)
{
private readonly string firstName = firstName;
private readonly string lastName = lastName;
}
I don’t love some of the problems this creates. Relying on developers to do the work of managing if instance variables/fields are mutable in this way seems more prone to mistakes.
I can appreciate the reduction in verbosity, but I’m not certain it will outweigh the potential risks
How are we not already relying on developers to manage if something is mutable? If it comes in via a normal constructor, it is mutable. It is up to the developer to save it as readonly. The same is true with this new system.
@@IAmTimCorey You make a fair point. I guess what I really meant is that we have to manage seperate names and whether we assign a value to a property etc. You're right that either way it falls to the developer, though.
Hi Tim,
Honestly?
What's the point?
If I use constructors to want or need to do additional initializations, I can't use this notation.
Maybe with other classes.
Then we have code again that was created one way or another.
What a load of garbage.
This has nothing to do with older or anyone else not wanting to do it this way, it makes absolutely no sense to me.
Yet another point where Microsoft continues to break C#.
Instead of keeping it clean, simple and standardized, Microsoft is doing exactly the opposite.
Not good, not good at all.
Sorry, but again I can't share your euphoria.
First, you absolutely can use this with other constructors. Second, the most common constructor is one that just takes in dependencies from dependency injection. Third, this is cleaner and simpler for a lot of cases (including those where you are using dependency injection). But most importantly, you aren't required to use it. That's the beauty of it. If you want to use the "regular" mechanisms, you can.
@@IAmTimCorey Tim, why doesn't anyone use the goto function anymore?
It's there, I can use it when and if I want!
But why doesn't anyone use it?
The problem is not whether I can use it or not.
The problem is that one person wants to use it and uses it, and the other doesn't (fortunately, no longer in the case of "Goto").
It also has nothing to do with being open to change.
It has to do with leaving straightforward structures.
The mere fact that you can't use this spelling in all cases should be a red flag.
I can't decide whether to always use it or not.
This gives the code a bit more complexity and makes it harder to read because a different form is always chosen.
For the idea of clean code, this approach is very questionable in my eyes.
You are and remain one of the best C# developers in my eyes.
But if I could wish for something, it would be that you would question innovations a little more critically and not always celebrate them immediately.
I don't know if you celebrate Christmas, but I hope you do and I won't offend you if I wish you and your family a wonderful Christmas.
Have a great Christmas and stay healthy, and have a wonderful and successful 2024
Thanks for your Content
Gotta say I'm not a big fan of this feature yet. I think it needs a bit more work and then it might be a great change.
While it is nice that the code is more compact and somewhat more clean, I don't like that it leaves all the parameters alive forever in the class even if you assign them.
And it kind of messes up the standard naming convention of _name being a private field, since it wants the exact same same.
The parameters don't live on if you overwrite them like so:
public class Test (string connectionString)
{
private readonly string connectionString = connectionString;
...
However, if you couple that with wanting to use the underscore but not wanting to use the underscore in the primary constructor, that's when you have the issue. And yeah, I understand that.
The entire implementation of primary constructors is off IMO. The biggest benefit of primary constructors in my opinion are quickly indicating the things that are necessary. They seem to have simply copy pasted the record functionality for primary constructors. They really needed to make it work with readonly services being inected, because as it stands now IMO it's something you're better off not using at all.
To push back a bit, we don't have that now. The services passed into regular constructors can be mutated. It is up to us to save them to readonly fields. Isn't that the same as what we have here?
Yikes. I smell trouble
Why? We've had this with Records for a while now, and they work great.
@@IAmTimCorey why not just use readonly fields? A record is a fairly new type so it could make sense there. It seems to solve a problem that we didn't have. In general that leads to complexity.
You can use readonly fields with this. The difference is how many lines of code it takes to assign the readonly fields. For example:
public class PersonModel
{
private readonly string firstName;
private readonly string lastName;
public PersonModel(string firstName, string lastName)
{
this.firstName = firstName;
this.lastName = lastName;
}
}
compared to:
public class PersonModel (string firstName, string lastName)
{
private readonly string firstName = firstName;
private readonly string lastName = lastName;
}
@@IAmTimCorey maybe I'll give it a try and see if I don't warm up to it lol
I don't really see how this primary constructor is that helpful/needed when there are so many other improvements that could be made to C# right now.
They are working on making C# simpler and less verbose. C# has been known as a wordy language without really needing to be. The same is true for constructors. Check out this comparison:
public class PersonModel
{
private readonly string firstName;
private readonly string lastName;
public PersonModel(string firstName, string lastName)
{
this.firstName = firstName;
this.lastName = lastName;
}
}
compared to:
public class PersonModel (string firstName, string lastName)
{
private readonly string firstName = firstName;
private readonly string lastName = lastName;
}
Both do the same thing. One is just a LOT cleaner.
This has been a highly requested feature. It is also something that allows for other things they want to do in the future. Think of these changes like dominos in a chain rather than individual features.
Bad feature. Inconsistent syntax. Confusing. Unnecessary.
It seems a bit, yeah.
As always, new people will get used to it, older people don't want to change, until in 10 years from now you won't find code in the "old"/current style anymore.
@@holger_p I do not think it is wanting to change or not, question does it adds any value. With so many options doing the same thing, new syntactic sugar sometimes seems arguably unnecessary/confusing.
@@0i0l0o The new value is less typing.
Around 1995 we had the same discussion on "I get along with Fax - I don't need email - it's confusing (to learn something new)".
You might be right, it's too many options, but to be backward compatible, they cannot strike out the old options.
If you want less options: Don't use the old ones any more ;-)
I think the habit of creating more classes has changed, so if you want to create 5 classes in 10 minutes, you need better features.
@@holger_p Please don't say, "Older people don't want to change"; it is ridiculous.
Primary constructors are, at best, a tiny subset of constructors. They are more similar to required properties than constructors.
You can not replace constructors with primary constructors, so it is not a matter of backward compatibility. They are different features.
I like the syntax, but it is a shame we will get more bugs due to the issues with mutability.
What C# needs is something along the lines of discriminated unions.
I don't know if it's just me, but doing it like this feels somehow ... wrong!
It is different, which can feel wrong, but the trick is to get past that to evaluate if it is a good thing for you or not.
@@IAmTimCorey - So, good or bad Tim? Is the jury out?...
Good in the right circumstances.
Hi
👋🏻
I am Optional Prime. We are waiting on Earth 😂
Wish the wait was over.