The New Extensions EVERYTHING Feature of C# 13!
HTML-код
- Опубликовано: 21 май 2024
- Use code GRAPHQL20 at checkout to get 20% off our new Getting Started with GraphQL in .NET course: bit.ly/3KaOI8z
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this video I will talk about a brand new feature coming in C# 13, called Extensions. This isn't to be confused with extension methods. Instead we can now have extension everything!
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elfocrash
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet
The one time when clickbait title isn't actually clickbait at all. The hype IS justified.
Thank you for the heads up
It is indeed
Use the DeArrow extension and you will get non-clickbait titles.
So it's not clickbait... Lol clickbait is only when it is not justified, if you give worms to fish without fishing them, then its not bait is food
If this is "changing everything", your code base has bigger problems.
Being able to add properties now is a huge deal.
What I still sorely miss is being able to take someone's class and say, "Um, actually, this Type DOES Implement this Interface! Here's how!"
Struggling to think of examples, but for some older code, it'd be nice to not need to use .Cast to get the correct type all the time, maybe?
You would be able to implement interfaces with extensions. It's the second purpose of extensions
You would probably like rust's traits
@@zachemny How does that work? Do you have a link to where it's described?
Adapter pattern
@@zachemny That would mean I could mock dependencies that I don't own and don't have an interface, awesome
I feel like inheritance is cleaner than explicit extensions? A video comparing pros and cons of both would be interesting.
Well, MS decided on many classes to be sealed, so extensions it is. Hopefully we can extend static classes like Math.
Yeah, I don't understand why explicit is needed... then again, I have questioned a lot of c# changes the past few years.... IMO they keep borrowing good ideas with poor implementations.... (primary constructors for example)
Keep in mind that explicit extensions are competing with inheritance exactly as much as old-style extension methods already were, which really is not at all. If you already have inheritance as an option, then all types of extensions become unnecessary, except when you want to add functionality to e.g. an interface or base class you don't control (or where it would be inconvenient to do so e.g. identical functionality for many implementations of an interface where you can't add a class to hold said functionality).
If you can add the functionality directly to the class you're working with, you don't need extensions. If you don't have control of the class, you can't add to it without extending or inheriting. And if you don't control how you get *instances* of the class, then extending is the only way.
The real comparison is implicit extensions/extension methods vs explicit extensions, and at this stage it seems to be simply an organizational mechanism, but also there may be instances where a particular set of extension methods/properties would only make sense to be applied to objects in certain states.
I so desperately want to be able to attach an interface to an existing class using extensions. So many times I wished for the convenience of having a method that takes an interface and passing some 3rd party object along except it, of course, doesn't implement my interface. So instead I have to write stupid wrapper classes all the time.
Just pretend it has the interface if it already offers all the methods and properties!
This. You hit the nail in the head
Yes, C# lang team calls it "shapes" AKA duck-typing
Great use case.
@@ryan-heath Is there a proposal for this somewhere?
Just use functions. Life will be easier. No more class, static, interface, wrapper etc...
(ps: it's good to use Interfaces in OOP or code that interact with OOP)
This is looking pretty clean. Unsure if I'll use it anytime soon, but it sounds cool.
Unrelated, I really hope they add readonly to the Primary Constructors. Bit annoying that it was pushed to replace those assignment only constructors, but didn't cover the common readonly usecase.
they could add the val keyword and copy kotlin syntax
Wow. So many questions.
How does serialization play into these extension types? What if you JSON serialize Person?
Can extension types have their own private fields/state? Could FavoriteDrink pull from a field that isn’t on Person, but is on Adult.
They can't own state. They are meant to add different behaviors to already existing data based on context in which it is used. I think the better example would be extending some PropertyBag types like ClaimsPrincipal or other Dictionaries with type safe properties.
I don't know, but given that Serialization usually is performed on the instance type using reflection I doubt that these extension methods will be included in the output. They are not really instances, i.e. they don't hold state.
As a counter example, assume serialization _does_ work. What would you then expect de-serialization to look like? You can't populate Age with a value since it does not have a backing field to store it.
So serialization is bust I am pretty sure.
@@sunefred Very interesting observations, I'd like to try this out and see
What about sealed classes? I'm assuming this would be disallowed but didn't know.
@@pfili9306 I'm not so sure about that. Check out the example in the official announcement docs. They show an example where classes Person and Organization are pulled in, and each Person object needs an Organization property passed in, but in this example scenario there is only one Organization object for the whole application, making the extra property for Person tedious to assigns.
So they make an implicit extension for Organization, add a private static Organization ourOrganization = new Organization("C# Design");, and then add a CreatePerson function that always assigns the new Person object with ourOrganization as the Organization property.
The property is static in this case, but I don't see anything mentioning that as a restriction rather than what happened to make sense in the scenario.
After all these years, I can't believe they're finally giving us extension properties. This is pretty hype as it's more than that as well. Although I have to say I'm a bit disappointed in the explicit extension. Don't get me wrong, it's a great feature. But in your example you check for their age, then inside the conditional branch you do the explicit conversion. The problem with this is that there is nothing tying the age check to the conversion. This relies on the developer to know when such extensions are valid or intended to be used. It would be nice if they added the ability to provide like a where clause on the extension declaration to define when it's valid. Then maybe you could simply do something like `if (person is Adult adult)`. This way you can make extensions only valid in certain contexts, and also be coupled to those contexts. But I mostly work in TypeScript these days and I'm pretty spoiled on the powerful type system there. This is already an absolute game changer as it is and I'm not trying to complain.
I wouldn't be surprised if they build up to something of that nature in a later release after they get feedback on this initial C# 13 implementation of it. I doubt they would put a boolean condition on the ability to cast to the explicit extension type itself. There isn't really a precedent for that, even with generic constraints. Doing so would hide the boolean condition from the calling code entirely (abstracted behind the cast operation).
However, I could see there being a "best practice" of defining, in such explicit extension scenarios, a `TryCreateAdult(out Adult adult)` kind of method that does the boolean check and sets `adult` to `this` when true. That way people would be able to leverage pattern matching and naming conventions to achieve that goal. IF that became so commonplace as to be annoying, then they might discuss potential strategies for optimizing the syntax or at least standardizing it. Perhaps with a `TryExtend` magic method, similar to what they do for TryParse and Deconstruct, etc.
The biggest pain point I previously had with extension methods has been with unit testing + Moq. I’m curious how mocking extended types would work with this new feature.
Its been on the cards for a while so I'm glad its almost here. The fact you can now introduce properties is really nice - great way to shape something you don't own or control.
Extension properties at last! I've been waiting for this since 2007.
Same.
Yeah, this is for me in this update.
Seems like the WPF team could have used this. Oh wait.
If, and that's a big if, you also get the ability to have fields to store.
@@McZsh
This would not make any sense, so I don't think it is a possibility to consider.
The one feature I would find really good is a way to extend interfaces to these types. If you have an interface like IAge { int Age {get;} }, it would be super cool if you could extend Person so it implicitly implements that interface so you can pass it directly into methods or constructors without having to create a new wrapper around them.
You would be able to implement interfaces with extensions, according to the initial proposal
Clear and clean. Goes for feature and explanation both
Yay! Looking forward to this new feature. Extensions that were essentially properties but addressed as methods always felt a little weird. This in addition to the explicit functionality is a welcome add.
I've been waiting for extendable properties for like a decade. So excited! C# just keeps getting better!
omg yes!! I am super excited about this for sure.
Finally, some love for extension methods! Extensions methods are bae and now much better!
So many questions here.
1. What about sealed classes
2. Is an extended property a real extention or is it added to the class itself on runtime and will it add to the PropertyList in reflection (I can see ORM frameworks fail there big time)
3. Because you can use this, does that mean you can invoke events (which can only be invoked privately)
4. Because you can use this, can you call private fields and methods in the class
5. Can you extend enums as well and add values
6. Is it just like an ordinary extention, and namespace based, or will the compiler do this during begin of runtime and extend the class itself.
7. Can the implicit extention also create custom constructors.
8. Can you override virtual methods
A lot to be exited about, but it is also a bit scary with this kind of questions. O lot of finding out
Very good video and in terms of functionality it reminds me of my rust trains
I used to work in js, and this sounds like a mixin... I love it!
I'm very happy about this, I've been asking for this feature for years and it seems to really deliver.😉
explicit one just seems like an other synthax for a derived class
I wonder if this will be the case for sealed classes from other libraries and how the polymorphism would play in our own library would an adult be a person?
But its not. See Rust trait system to understand this much better.
@@rogeriobarretto but sealed classes are sealed for a reason. It's just stupid to provide a feature (inheritance), to provide the tools to control this feature (sealed classes), and then to provide ANOTHER feature to ignore the restrictions (explicit extensions).
I believe explicit extensions were invented for anything else except inheriting sealed classes.
@@rogeriobarrettoin terms of serialization, `Adult` does not exist.
@@user-qp8bt7gq4b
The problem of ignorance is that it is impossible to beat without the person wanting to learn. Try to understand first what is an extension method and what it solves before arguing on internet.
Love it ❤
I will use it instead of a static class
some of these features are building blocks for Descriminated Union ❤. I love Extensions everything
I absolutely like this feature. I'll want Smart Enums to be in C# like the Java language has
Everytime I wanted to create a smart enum, I ended creating a class with some default values and a parser. Every time I used it, I always figured out that I may need something more flexible than a fixed list of values, not mentionning that a bunch of procedures should be handled by a factory.
I really think that there is fewer use cases for smart enums than originaly expected.
Bro finally C# is getting some good stuff
Records make a decent replacement for smart enums, right?
For anyone here confused with extension methods, I will ask you to search about a thing called 'universal function calling syntax', and then to experiment a bit with C# actual extension methods.
They don't do anything that is not already possible, but make the code cleaner and more sequential.
It is the reason you can write:
var arr = [ 1, 2, 3, 4, 5, 6, 7 ];
var even = arr.Where(x => x % 2 == 0).Select(x => x * 3).Select(x => $"Result is: {x}");
Instead of writting:
var even = Select(Select(Where(arr, x => x % 2 == 0), x => x * 3), x => $"Result is {x}");
Both things are literally possible to do, but one of them is clearly more annoying, noisy and requires more cursor movimentation (if you don't want to store everything in a local temporary variable, which is also annoying).
To be fair even with the extensions, you would probably write it in a way that is on multiple lines i.e
var even = arr
.Where(x => x % 2 == 0)
.Select(x => x * 3)
.Select(x => $"Result is: {x}");
and you would probably write the latter as:
var a= arr.Where( x=> x%2 ==0);
var b = a.Select(x => x * 3);
var even = b.Select(x => $"Result is {x});
The syntax is a bit more concise and readable. But I think the game changer is it makes writing more readable code the easier default. Whereas before it was kind of up to one programmers interpretation, with extensions you are pushed in the direction of writing good code. The only part that is a bit harder to read is that all of the lines eventually return a value that is stored in the variable at the top of the operation. I think if you wanted to go to the full 9s you could have a .StoreAs extension that you wrote at the end. That would make it read better in a left to write fashion, but would likely require more in depth changes to the language
so it would become
arr
.Where(x => x % 2 == 0)
.Select(x => x * 3)
.Select(x => $"Result is: {x}")
.StoreAs(IEnumerable even);
@@NickSteffen
No? I don't often find people that would write the version with extensions using intermediate variables, this don't make any sense unless you are doing something very fishy. Also, I'm considering multiple lines, I generally use them as well and with extension methods it feels much natural, sequential and direct.
And for the storage part, I think you are just not used to how programming languages work, I really don't think this is a problem per se and I recommend delving into studies to get better at it over time. With time you will be able to see how this all works.
But for a brief explanation here, functions return values, and values in C# can be objects that have methods OR extension methods. When you write:
var even = ar.Where(x => x % 2 == 0).Select(x => x * 3)...;
You are just saying::: take this array, filter all the elements where 'element % 2 == 0'; then take the returned result and map each element on it as 'element * 3'; then take the returned result and map each element on it as 'Result is {element}'; then let the result be returned into the variable attribution.
You can write the same thing without extension methods (althought it would take much more work to do so), take a look at the builder pattern and how it is implemented and I think it will be clearer for you how this generally works.
@@diadetediotedio6918 I think you completely misunderstood my answer… The example with intermediate variables with describing was you would do if extensions didn’t exist. It was a counterpoint to your second example on how unreadable it would be. A good programmer would never write it in that unreadable way.
My last point was a completely theoretical what if, yes I understand program languages don’t work that way. They also didn’t work “that way” before extension methods were a thing. Fluent/ universal method style is just changing how programming languages work to bend the syntax to how human language works. So the fact that they don’t work that way now is irrelevant to the point.
Also C# can in fact work this way in some very limited cases though, since you can declare variables in a dictionary’s TryGetValue method. So for example you can:
arr
.Where(x => x % 2 == 0)
.Select(x => x * 3)
.ToDictionary( ( x => x),(x => $“Result is {x}”))
.TryGetValue(6, out int result)
Notice how at the end I’m both declaring a value and saving the result into it. You can do the is in some other places like type checks in if statements ex:
if( x is string y)
Console.WriteLine(y);
This type of style is more easily readable for humans as we read continuously in one direction. You don’t have to jump back to the top to see where the variable is being saved. You could absolutely change c# to do this in more cases fairly easily.
Now would it be a good idea to do that… I’m not sure, it would at least be interesting.
@@NickSteffen
My second point was to highlight that writing in the same way you would write using extension methods would be uglier, I'm not saying that necessarily you would do that (althought I'm pretty sure many people would do). If this was your objection then read again my note on storing things as intermediate variables to improve clarity (implied from context).
Next, it is not irrelevant. The fact that we can write fluent functions in that manner is precisely because they work in that way, it does not "change how programming languages work" even if it is to align it better with 'how human language works" (which I can partially concede).
Your example with dictionary don't make sense as well, it is a very bizarre way of writting what would be much better written as just .First(...) or .FirstOrDefault(...), to create a dictionary you would already need to iterate through all items so there is no advantage on using it. Also, this works that way in this specific case because then you are fundamentally dealing with another resource of the language, a similar result could be achieved using 'ref' and the semantics are not the same, TryGetValue returns something (a boolean confirming the existence of the item) and it stores the result in the out pointer (because at the time C# had not fast and reliable booleans, many languages nowadays don't have an 'out' thing for example).
As for the 'x is string y' example, it is another completely different mechanics of the language again, there is nothing to do with how 'out' works. The convenient 'x is string y' is a modern construct (in early C# versions you had to type manually 'x is string' and then '(string)x' or do 'x as string' and then 'x != null').
As of your question about this being more "easily readable" because it reads continuously in one direction, I don't think I necessarily agree with you absolutely on this. I can buy the point that this is better , but I wont that this is the step to follow for many reasons. I know you are not sure about if this is a good idea, but I'll argue as you held that position (so I can focus on responding anyone who is willing to defend it):
First of all, because it is untrue, humans also write things in a name -> description fashion, for example when we respond to someone we can do:
A. (responds to point A)
B. (responds to point B)
And when we want to describe something we have a resource in language that is ':', so we can say:
something: this is something (explains)
Even when I'm writting this response, and when you did wrote your response, you used attribution in this same sense (for example when giving the example, you said 'ex: (code)'). So it is untrue that this is a direction that should be followed by readability.
Second, programming is for humans the same way mathematics is also for humans, the same way everything humans do is ultimately for humans, and in mathematics nobody is arguing of how f(x) = y is a terrible syntax and nobody understands it, you are removing the formal aspect of programming which is that makes it easily readable and generally predictable (human language is inherently noisy and ambiguous, this is why even when programming languages try to approximate to human language they keep a safe distance to what is actually reasonable).
Third, because this would make a radical rupture between every single language out there that don't work that way. When you make a change that affects the entire way we reason about programs in a specific language, this should be EXTREMELY more justified than that, because then someone writing C# will arrive in another language (like C, C++, Rust, Go, Kotlin, etc) and suddenly everything he knew will not be valid here, this is one of the reasons of why even arguable that indexes in programming languages should start with 1 (because we usually start counting with 1 in human language) this is not necessarily a good idea as it would break many assumptions when moving from one language to another.
As for the end, you can also use extension methods to achieve what you want, you can for example write a:
public static void StoreAs(this T self, out T @in) => @in = self;
And it would work like you wish.
In kotlin, it’s common to write extension methods for types within your own code base because it allows for utilities that don’t clutter up the code of the class itself.
Now take val and var from kotlin, too.
That is really nice. I need this now! :)
Wow i really like how they solved the problem of adding extension properties. 👍
I don't quite understand the difference between "explicit extension" and classic OOP class inheritance
finally !! finally ! waiting for a long timmme long time ! :D Huray ! :)
Interesting path... It seems not only me is using Downloads as a Temp folder :D
This Is the Way
I've been waiting for this forever! Next question.... in these extension "classes", can you also define extension operators??
This looks really good, though I am somewhat sceptical of the practical benefits of explicit extensions. I just can't see them actually being used but I might be wrong.
Most wanted feature: anonymous object spread operator like in js/ts e.g.
var shirt = { Name = "Shirt", Size = 20 };
var shirtWithDescription = { ...shirt, Description = "A red T-Shirt" } // { Name = "Shirt", Size = 20, Description = "A red T-Shirt" }
I would see the benefits of explicit extensions if they were not tied to a specific type, like for example
public explicit extension Named
{
public string Name { get; }
}
So you would be able to do structural typing and this would be extremely useful.
But I'm not sure if this syntax allows it, as I didn't readed the docs of this yet.
I feel like explicit extensions are really missing some way to enforce whether it can be casted. Like in the example Nick gave, I'd want to actually be able to ensure that person is only an adult if person.Age >= 18.
@@normalmighty
Well, for this you can use a new type pattern, I don't think this is the role of extensions on themselves.
I just don't see what's the supposed benefit of explicit extensions over simply encapsulating the type...
@@mbpoblet
A. It is more ergonomic as "encapsulating the type" would require you to make a wrapping method for each property/method of that same type OR expose it through a property.
B. You can use it over generics easily without needing to cast in some specific circumstances (which would allocate memory / this is solvable with wrappers but the friction would be even bigger).
This is quite an exciting new feature. Feels clean.
Extension methods completely changed my life as a programmer. Looking forward to this!!
That explicit extension use case is actually interesting. What it almost lets you do (or what that syntax almost seems to let you do on the surface) is have a class more or less inherit from multiple classes at the same time, not just interfaces. Like if there was some sealed class from a third-party library that I wanted to add support for say a custom serialiser system I was making, I could add an extension to that class which defines the serialise and deserialise methods, even though I can't edit that class directly.
Hmmm. Yeah, I'd be interested to know how that works with reflection APIs. In order to REALLY be useful for dynamic situations, you'd need `typeof(Person).GetProperties()` to include stuff like `Age`, etc.
I have been waiting for this for years and years.
I've been waiting for this feature for years. This and DUs, but I think I need this one more.
Is imposible try to catch c#. We need some stability for 5 years. Too many feature. We don’t use 20% of that feature
Great content as always, Nick. As you were discussing the explicit extension, I couldn't help but wonder how this is different than a subclass. Then that made me wonder if the implicit extension is different from the static extension method in that the implicit extension is actually just a subclass where the base class can be implicitly converted. So if I have an implicit extension method, is the the runtime actually implicitly coercing the base class to the subclass then calling the extension method? If so, are there any performance considerations there?
Would these extension properties work for model binding in Maui? They could be useful for adding properties to a model that would previously require a converter.
Great content, Nick! One question: is the Deep Dive GraphQL planned to be released as well? Thanks
This gives us a lot more power. It might be an anti-pattern for 'closed'/sealed classes
Return type: this .. similar to typescript, works really nice for fluent api builders, when extending, returns the type correctly
I've been waiting for this for 4 years!
why?
@@TheOnlyDominik
Cause it is amazing for structural parametric polymorphism
@@diadetediotedio6918 ok. I don't need any unnecessary theoretical features.
@@diadetediotedio6918 I only have 30 years of experience in software development, it's too complicated for me.
Bro some of us have been waiting since 2008
Interesting. Does this work with data binding, eg in a WPF app?
Definitely like the extension properties.
Though I'm not sold on explicit extensions since it seems to leave us with 2 overlapping definitions for polymorphism. What's the use case for this?
I wonder how this compares to sth like Traits in Rust.
Would it be possible to use extensions as generic type constraints?
Sth like Add(T value, T other) where T has extension AddOperatorExtensions.
Or would it be possible to completely omit the generic one and use a similar approach to the dyn keyword of rust?
Sth like Log(LoggableExtension value) => value.Log()
This would make C# much more powerful
I'm not 100% sure, but I don't think you cane use extensions as type constraints, but you will be able to extend a type to implement an interface, so while the syntax in your example might not work, you will be able to do effectively the same.
It looks like swift extensions that rust borrowed from (and have stated it in the passed with traits) which is awesome. It would be better if you can just inline extend it like in javascript with prototype i think it is. The implicit to explicit is a cool feature too, to define a custom type and type the variables. All in all great feature.
Very cool, but I really do hope they also add support for adding interface implementations AND for adding interface implementations to structs, both for static members (eg. operator overloads) as well as instanced. This would be huge, because it could introduce very simple ways of making an external library compatible with your system.
One video I'd really like to see from you once this gets implemented is the performance comparison.
Does having these types of extensions allocate extra memory?
And is invoking the Age property trough an extension slower than if it was a property on the Person object? I know that even if it was slower, the difference would probably be small, but if you were to use this in a more performance critical scenario, that small difference would add up quickly
Will it also be possible to implement an interface as an extension?
Well, I definitely have use cases where implicit extensions will come in handy. Like, I need them already yesterday. 🙂
That is why I chose .NET over any other language for API (and others) development. C# is constantly on the move to become better and not becoming complacent and releasing updates every 300 years, unlike a certain cup of coffee, until it had a new competition.
Nice feature, can you test it with JSON serialization and deserialization, does it include the extension properties in json string? Can you add Json attributes (such as name) to the extensions properties?
This feels like Typescript and that's very cool, it literally solves the problems with inheritance, so cool!
I can already say I am going to use this all the time. I would like it if they made it slightly more like Rust's trait impls than it already is, and let you implement interfaces as an extension.
*Absolutely LOVE it!*
Amazing feature, can't wait to use it in 2040 when Unity finally implements C# 13
Great stuff, Do you happen to test/check how this implicit/explicit extension properties will behave when serializing/deserializing to a Json for example?
Wow, that's a really useful feature!
Thanks for the video Nick!
Great as always.
But one question: can these extensions add & modify private fields? If so then i see problem if you are using DDD and have business rules in your model which can be jailbreaked by simply creating an implicit / explicit extension.
Or may i´m wrong here?
They cannot, extension methods in general are only normal methods with a nicer syntax.
The thing interesting me here is both the possibility of having some niceties (like .dp/.sp/.rem of Kotlin for UI) and a possible structural parametric polymorphism.
Do you know if there is any information on how these additional members appear in reflection APIs when using implicit extensions? Like, if I do `typeof(Person).GetProperties()`, would I be able to see `Age` in some capacity?
Towards type classes. In Scala 2 it used to be called "implicit" and now "given". But in Scala it can be parametrized like for ex ToStringable { string ToString() }. Can we now define such a crosscut concept and implement it for neccessary types?
I tried doing the exact same thing years ago when I was trying to extend Tasks then realized I couldn't and then they finally added it. That is actually a feature I do agree will actually change the way we write C#
Yaaayyy!!! Can we have interface constructors and static methods now?
This seems to be a game changer, specially the explicit declaration
For the follow up, olease discuss full-on duck typing and how this dovetails (ha) with that eventuality.
Does new extension approach work for sealed classes ? Because it seems it's only scenario where you cant inherit class and want to extend it with this approach. Making a new type with extension looks wrong to me, but it seems noone really care about clean code anymore
These are still just extension methods with a new syntax. The whole point is to allow for cleaner code.
Now this is how C# should be extended...pun intended.
One weird feature I'd like is something like `foreach { ... } empty { ... }` (also for `for`) Where if it doesn't go into the foreach (or for) body because the enumerable is empty or what have you, it will execute the content in the empty body.
Well, you can write an extension:
IEnumerable.ForEachOrEmpty(Action itemAction, Action emptyAction)
@@theMagos Yeah, but I want syntactic sugar.
This makes the reference to this a bit vague, but I like it. I wish they’d added another keyword than ‘this’ though. I do like the implict and explicit pattern that is used for casting operators now being added to extension methods.
C# is on the right way from inheritance to composition
Why has it become cool to hate on inheritance now...
@@jonas9 code becomes non testable because of inheritance in most cases.
@@jonas9 I've hated inheritance since it was invented! ;-)
@@jonas9because when you change the parent you change all its children. This is very problematic.
@@jonas9 I don't get it either. If an existing class doesn't have all features you like, just make a new one that inherits from it. Why are there new fancy features required?
Does this require a new runtime or can this also be used in older .NET Core versions (just a language feature)?
Cool! Will fields be allowed too? The way you example-property worked it's basically still a method, with the syntactic sugar of a C# Property which is nice. But i wonder if i also can hold extra state-information about that Person-class. Can protected members be accessed from the extension, or still public only as before? Thanks for your education-work :)
Nice Video but leaves many questions for more.
What about Enumerables? Extension methods are the way to go if you want to give them some logic.
And struct, generic classes, records, interfaces (shouldn't work) ?
But very interesting
There's going to be a presentation about extensions at Build on the 23rd (tomorrow at time of writing)
The question I have is can this extension implement interfaces. I find the need to add an interface to a type I don't control many times I have to resort to wrappers.
Great. C# is catching up on F# step by step :-)
Does F# still require you to write your functions in the proper order for them to be seen by the compiler?
Love it!
Now I'm curios - will it be possible to mock such extended methods and properties? One of the disadvantages of current extension is that it is a static methods and we can't mock them.
In some sense. You can have an extension that inherits another extension and use the new keyword to shadow the base extension's member.
I like it, is it now possible to extend static classes as well?
Thanks for the heads up and the interesting intro, Nick!
Would you mind clafirying why we need to consider leap years to find the age? Am I missing something really obvious? 🙂
He means birthday. Taking year - year gives the wrong answer by 1 after your birthday.
@@gbjbaanb thank you, that's what I thought it may be the case but better to be safe than sorry. Essentially the year subtraction could make you older by 1 year, if you haven't reached your birthday month yet, if I understand correctly.
Ohhh that's nice!
Might also be the way to get the last persistence concern (i.e. the Id property) out of my DDD core... 🙌
How is the access level with that new features? Will it be possible to also get access to protected or even private fields, or is in that scenario just like an extension method?
They are just extension methods, so public members only.
What is the practical difference between the explicit extension and inheritance? I have no experience with extensions so i don't know.
In your example what does PersonExtension indicate in your implicit example? Is it just a name like the class that contains your extension methods?
Yes, it's just a name for the extension (which is not a class any more, it's another "thing").
Whats the difference between using explicit and just extending the class?
Does explicit override sealed ?
Will these extension properties will be included in ef core model?
what problem does this solve that inheritance doesn't? curious on if it works with sealed & static classes
I love this new feature!
will we be able to use pattern matching "if(person is Adult adult)"? And is it possible to add operator behaviour to any type? I often want to add the values in a vector but there is no built in + in vector, and you cant do it yourself directly on the System.Numerics.Vector class so far
Can't wait for this feature. I hope the IDE will help make it obvious where code is comming from, is some property from third-party library, is it from your own extension or from some other third-party extension library. Otherwise it would be a very confusing trying to some out where some random property is from. 🫠
brilliant!
is there a way to already play with this?
i can’t find it on sharplab
It's basically reimagining of OOP with some additional features
This is pretty great. Discriminated unions is THE feature to fix exception nonsense in enterprise code or OneOf nonsense in smaller personal projects.
Very nice!
Hi. What are the benefits of this in comparison to partial class for implicit extension Person or Child class of Person for explicit? (of course assuming the Person class is not sealed)
Partial class needs to be defined in the same assembly. So it won't work for types you don't own (that are in libraries/other assemblies).
Child class - first requires the base class to not be sealed, but also if you do create a child class - you then have to allocate it, on top of already allocated Person object. Let's say your Person object comes from external (not owned by you) repository - You call var person=repository.GetPerson(...); and get that. To then cast it to an Adult you have to call new Adult(person); and have that constructed, since you cannot just cast to a child class from a base class, if it's not that to begin with. That will end up allocating a whole new object on a heap.
Meanwhile the extension is just a facade over the type, masquarading it as a child type. It does not re-allocate it, it only "pretends" it's an Adult type by exteding it's capabilities. You can then create methods, in your own code, that will accept Adult type and use it as if it was an inherited object, and then return it to not owned part of the codebase, as it's still "just" a Person.
How do you test this ? I tried the SDK 9.0.100-preview.5.24274.2 from the Daily Channel, but with it Visual Studio doesn't know any "public implicit extension".
Because it's not out yet
The future I would most like in C# is the ability to make subset types easily from another type, like we get in typescript.
Awesome feature!