Transcript from the "Type Q&A" Lesson
>> First, I'd like to address some questions that I see in chat. So Dimitri asks, would it be correct to say that if I say that generics used are used more often when we write libraries. So Dimitri asks, are generics more appropriate to use in libraries versus app code?
[00:00:25] I don't really think that it hinges on whether your code is library or app related. For example, I know of many apps that have use of generics in their data layer where they might have some concept of record type. Maybe if they're hitting like a SQL database, they have a primary key that's always ID, and they want some predictable pathway for going to fetch some information using generics and app code.
[00:00:58] In that area it's quite common. I would say the more reusable, the more reusability is a concern, the more you're gonna want to Leverages generics for that purpose. Yeah, libraries tend to get reused quite often. But it's not limited to libraries for sure. Leslie asks, I feel like generics can easily see him so complex because everyone's using random non-expressive letters.
[00:01:31] To represent types, is that considered the standard? There is no standard, I would say it's the norm to use these capital letters starting with T, but that is a leftover remnant from the C++ days. Sort of started in C++ with template classes, and then made its way into generics and Java and C-sharp.
[00:01:54] And now it's sort of this pattern that everyone who's used this concept before in other languages, they're used to doing it that way. I do 100% agree with you though. That, we don't like single letter variable names for values. Why are we cool with single letter names for types?
[00:02:13] That's a very fair point. The good news is there's nothing that stops you from giving these more meaningful names, although you're going to come across a lot of code that just sort of has these very abstract letters. That make it difficult to sort of read the code, and understand what the intent of the developer was.
[00:02:32] That's a totally fair point.
>> We see here like we use this extractor type, special type from the library, is this equivalent to the end operator? We use the model at the beginning with the key off date we combined and to extract on it the case on it, is extract basically doing the same thing or is there a difference?
>> That is a very, good point. So, there, I'm not sure if there are a 100% the same, but it's true that. The, it's true that the intersection type operator, that end type does accomplish things that are also possible using this syntax, with this arrangement of things. Now, I think you might get some side effects.
[00:03:31] But like in some cases, I'm reluctant to say that it will always work. But that's a very, very good point you bring up. I think, logically it makes a lot of sense. You're trying to get, the portion of one type that also is assignable to another type it would seem that's what we're dealing with.
[00:03:54] I just don't want to unfirmed say, yes they're absolutely the same thing. But they seem like there could be. This obviously you can't do with the end and the or would not give it to you either. Does that make sense?
>> So this exclude is sort of like the end to end it's useful to have a generic that will do that for you.
[00:04:20] And by the way, you're also going to see that there are things in fact, we're about to talk about the infer keyword. There are things that make it beneficial to use type params and to use a generic for extraction of some subpart of a type from another type.
[00:04:45] So I think you'll see a rationale for why it makes sense to do this shortly.