Alias Any Type in C# 12
ฝัง
- เผยแพร่เมื่อ 18 ก.ย. 2024
- In C#, you can use a using directive to shorten a command. For example, instead of saying System.Console.WriteLine, you can add a using System directive and then just call Console.WriteLine. However, with .NET 8, we can now use the using keyword to alias any type, allowing us to make our code cleaner and clearer.
Full Training Courses: IAmTimCorey.com
![HIWWHEE | OHM [Official MV]](http://i.ytimg.com/vi/OJJLtTLqLag/mqdefault.jpg)
You should add links to official documentation in the description when covering this kind of topic.
I second this, Tim. Would be very helpful to add links. Perhaps in the description area?
Thank you for this quick information!
You are welcome.
C# is an OO language. We have and use classes for a reason. If you need something more lightweight, go with a record. Tuples are already kind of naughty but nice in a pinch, like you said, especially for return types from an impromptu method in that same class/file, but if you're using a specific tuple so much you feel the need to alias one at the top, that already has code stink (smell + 1) imo. You can create classes (or records) within classes if you don't need it outside and/or don't want it to "pollute" the rest of the codebase. Except in very very rare circumstances (I've seen aliases used only twice in 20 years, both to clear up namespace/naming collisions), this really shouldn't be (and I predict won't be) used in production code or on a team.
I personally haven't used this yet but I can't think of a single reason it could not be used in production if used appropriately.
This reminds me of a silly sonar cloud "smell" we have at work that wastes time for no benefit, "remove unnecessary parentheses"
Like sure you could use a record inside the class but what Benefit does that add over the tuple if the tuple does everything you will ever need (besides subjective developer preference and familiarity)
@@ace90210ace I'm not arguing against using a tuple. I'm saying if you are using that tuple *that* much, why would you not use a class or record? It's clearly a meaningful object in your application if you're using it that much. This is just one more redundant syntax the C# developer has to learn -- a solution to a problem that doesn't exist.
A tuple is an object. The difference is that we do not need to declare the object or have it pollute our namespaces when it is only used for a particular purpose. Let's say you want to return a first and last name from a method. You could create a class for that, but now that class could be accidentally used instead of the correct class that includes ID. So, you use a tuple instead. Then, in another class, you call that method a few different times. You want to make your code easier to read. So, you create an alias. That isn't a code smell. That's making your code easier to read. It would not improve your code to add a record or a class. In fact, it would probably make things a bit worse. You can't just convert a tuple to a record or a class. You would need to parse the return information and then fill the record/class or you would need to create a constructor that took the tuple and converted it. Why do all of that work when you can just alias a tuple?
I'm not saying that this should be used all of the time. However, there are cases like the above where it makes sense to use it to make your code more readable.
Tuples are not naughty, they're a basic mathematical object, just like numbers and sets.
@@IAmTimCorey Tuples are useful, absolutely, but aliasing a tuple is no bueno. It makes sense in demoing the feature that was added - sure. Outside of that, I don't see any practical use for it at all. I suppose we shall see in time how used or not used this feature is. Love your tutorials and channel, btw. It's not your fault the C# team is throwing in extraneous features. :)
Thank you Tim.
As always, I learned something new from your video.
Great teacher.
Thank you very much.
You are welcome.
The „using static …“ is really helpful when e.g. using libraries like MoreEnumerable. It allows you to use a specific extension method and not all the extension methods which might result in conflicting method names with other libraries or custom extension methods
Thanks for sharing!
Great video thanks Tim! Not totally sure I agree that more options = better though. Something I love about writing Golang in a team for example is that peer reviewing feels easier - I guess since there are generally only one or two ways to get things done so there's a strong sense of familiarity in lots of codebases. Gets junior devs up to speed faster too IMO!
I get that. There are a couple of problems, though. First, having only one or two options means you aren't able to do things you want to do. That's why language sprawl happens. The reason Go hasn't experienced that yet is because it is too young. It will get there. Second, options allow us to build applications in the way that we feel is best. Code is meant to be read by humans. We get to choose what we feel is the most readable way of expressing the logic of our application.
Not having choices (or many choices) might feel like a better option, but it is restrictive. As long as you don't mind playing inside of those restrictions, you are fine. However, once you start hitting the edges of those restrictions, you start to think about requesting more options.
I often see people saying "the language has too many options", but if you look at even their own posts, you will see them asking for changes. They often want changes, but only their changes. If the changes aren't their changes, they complain about the changes. That's why the suggestion sites for Visual Studio changes and .NET changes are overloaded with change requests.
Last point: you used Go as an example of how you like things to be done. That's an example of having options (different languages) so that you can express yourself the way you find is best. We don't NEED Go. C# can do what Go can do. The same way we don't NEED Rust, C++, Java, Python, etc. But those options make the marketplace better. Personally, even though I love C#, I REALLY don't want to get to a place where C# is the only software development option available (or even one of a couple). The other options allow me to make better choices for every situation I face.
At the end of the day, I get it. Too many options makes it harder to understand the language, harder to get started, and harder to keep a team focused on the "right" way to do things for the team. I'm just arguing that while those are downsides, they aren't as significant as the upsides to having more options.
I learn a new word today, Tuple. Thanks Tim, great watch.
Here's a 10-minute training on them: th-cam.com/video/QC6hpl2iU0c/w-d-xo.htmlsi=0yXxxPBF52EWE5rN
Thank you, Master, for the clarification; it's great as always
You are welcome.
Another banger video. Tysm Tim 💓
You are welcome.
I addedd like/thumb to another comment and add it "like a bonus"- your prompts are useful always, thanks
Awesome, thank you!
When is ur game development course launching for devpass?
When it is complete. I'm taking my time in order to build the best content possible. When it is fully complete, I'll add it to the DevPass.
@@IAmTimCorey Thank you, I really enjoy your teaching style. waiting for it!!
Can you do all the features released in C#12 and .net8 with examples?
Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/
this is hot
I'm glad you like it.
Program statements, not commands. Terminology matters.
I was referring to the line you write in your code, not the using statement. So "WriteLine" instead of "Console.WriteLine". The word "command" there is a general term for the code being written, not a specific type of code. This would be general language. I don't think that it confuses people into thinking I'm referring to something else when I say command. I think there is a balance to be hit between using specific language for specific things "using statement" vs "using directive" for instance and using general language that is easily understandable by the average user ("command", "code", even "programming").
Imho, the people, who adding so much features are idiots.
Idiots, because they make complications in cognitive perception of code for people, who work with already written code by other people. It makes code behaviour more and more unpredictable for human brains. More and more abstract.
10 ways to do same thing is not a feature. And never was.
This is how i see that.
I see this perspective a lot, but I disagree with it. Part of the reason why is because it is rarely a perspective of people who have a really wide view of software development. Meaning, have you developed hundreds of applications across companies of all sizes? You see, that's what Microsoft is working with. They have hundreds of thousands of different situations to support. They see the entire range. What might be useful to one group might not be to another. More recently, they have worked really hard not to break existing things when making changes. This allows existing apps to continue working, it allows for easier upgrades, and it still supports newer ways of doing things.
This specific feature is a bit more niche. That means if you don't need it, you might not see the need for it. There can be a lot of people like that. However, that doesn't mean it isn't valuable. Nor does it mean it has to impact you. If you really don't like it, don't use it. Sure, you might get on a project that uses it and you have to support it. In that case, either you will see the value of it (someone had to have thought it was valuable) or you can work to eliminate its use in your codebase. However, I really don't see how this will hurt you. This aliasing only works in the file you are in. That means you don't have to hunt it down to find it. Turning it off should be really easy too. That means it isn't a feature that should cause you problems.
At the end of the day, I really don't like it when developers call other developers "idiots". You aren't in the decision-making process for these features. You don't know what goes into the process. But instead of forming an opinion like "I don't like this feature" or "I don't think I'll use this feature", you attack the team. That doesn't make anything better. That makes the community a little worse. I would encourage you to rethink how you interact with others.
This is how I see it.
I'm the first one to watch 😀
👍