Interfaces with code in them
-
Just had one of those moments where I thought I was going mad. I had put a method implementation in an interface (not quite sure how I got there) and not only did the compiler not complain, it actually worked. After several minutes questioning my sanity, I recalled something new in the language about this, and it turns out its C#8 'default implementations' or some such. Thus the central tenet of an interface 'can't contain an implementation' is gone, well sort of. I think its probably the case that the source can contain an implementation, but its just lifted into the implementer by the compiler, which I guess creates a type of static polymorphism. Haven't actually read about it too closely so that might be wrong. There certainly seems to be parallels to a virtual function. I really feel I need to sit down and think out my understanding and implications of all this now. It warrants the question whether they are messing with the language too much? As it turns out this feature is of use to me if I don't think about it too much, allowing me to provide a simple helper property which just combines other properties, but it seems an interface is just that bit closer to an abstract class now. I have to say these updates to the language generally aren't met with pleasure by me. They're just more things I feel I need to keep on top on rather than things that actually make my life easier. Old dog maybe, I still haven't got over extension methods yet!
Regards, Rob Philpott.
-
Just had one of those moments where I thought I was going mad. I had put a method implementation in an interface (not quite sure how I got there) and not only did the compiler not complain, it actually worked. After several minutes questioning my sanity, I recalled something new in the language about this, and it turns out its C#8 'default implementations' or some such. Thus the central tenet of an interface 'can't contain an implementation' is gone, well sort of. I think its probably the case that the source can contain an implementation, but its just lifted into the implementer by the compiler, which I guess creates a type of static polymorphism. Haven't actually read about it too closely so that might be wrong. There certainly seems to be parallels to a virtual function. I really feel I need to sit down and think out my understanding and implications of all this now. It warrants the question whether they are messing with the language too much? As it turns out this feature is of use to me if I don't think about it too much, allowing me to provide a simple helper property which just combines other properties, but it seems an interface is just that bit closer to an abstract class now. I have to say these updates to the language generally aren't met with pleasure by me. They're just more things I feel I need to keep on top on rather than things that actually make my life easier. Old dog maybe, I still haven't got over extension methods yet!
Regards, Rob Philpott.
Yes, default interface methods look like a complete mess to me:
Safely update interfaces using default interface methods in C# | Microsoft Docs[^]:
Interfaces can now include static members, including fields and methods. Different access modifiers are also enabled. The additional fields are private, the new method is public. Any of the modifiers are allowed on interface members.
Thankfully, it's restricted to .NET Core 3.0 or later. With no SSRS support in .NET Core / .NET 5, we're sticking with .NET Framework 4.8, so our interfaces shall remain untainted by this abomination. If you're interested, Matt Warren digs into the low-level "behind the scenes" details here: Under the hood of "Default Interface Methods" · Performance is a Feature![^] Oh, and things are set to get even worse in C# 10: [Proposal]: Static abstract members in interfaces · Issue #4436 · dotnet/csharplang · GitHub[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
"These people looked deep within my soul and assigned me a number based on the order in which I joined" - Homer
-
Yes, default interface methods look like a complete mess to me:
Safely update interfaces using default interface methods in C# | Microsoft Docs[^]:
Interfaces can now include static members, including fields and methods. Different access modifiers are also enabled. The additional fields are private, the new method is public. Any of the modifiers are allowed on interface members.
Thankfully, it's restricted to .NET Core 3.0 or later. With no SSRS support in .NET Core / .NET 5, we're sticking with .NET Framework 4.8, so our interfaces shall remain untainted by this abomination. If you're interested, Matt Warren digs into the low-level "behind the scenes" details here: Under the hood of "Default Interface Methods" · Performance is a Feature![^] Oh, and things are set to get even worse in C# 10: [Proposal]: Static abstract members in interfaces · Issue #4436 · dotnet/csharplang · GitHub[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
static members as well?? Well, at this point that makes entirely zero sense to me. Oh, the horror..
Regards, Rob Philpott.
-
Just had one of those moments where I thought I was going mad. I had put a method implementation in an interface (not quite sure how I got there) and not only did the compiler not complain, it actually worked. After several minutes questioning my sanity, I recalled something new in the language about this, and it turns out its C#8 'default implementations' or some such. Thus the central tenet of an interface 'can't contain an implementation' is gone, well sort of. I think its probably the case that the source can contain an implementation, but its just lifted into the implementer by the compiler, which I guess creates a type of static polymorphism. Haven't actually read about it too closely so that might be wrong. There certainly seems to be parallels to a virtual function. I really feel I need to sit down and think out my understanding and implications of all this now. It warrants the question whether they are messing with the language too much? As it turns out this feature is of use to me if I don't think about it too much, allowing me to provide a simple helper property which just combines other properties, but it seems an interface is just that bit closer to an abstract class now. I have to say these updates to the language generally aren't met with pleasure by me. They're just more things I feel I need to keep on top on rather than things that actually make my life easier. Old dog maybe, I still haven't got over extension methods yet!
Regards, Rob Philpott.
Interfaces are somewhat lame, but needed; extensions work here and there; inheritance is "bad". I think it provides some middle ground. If it avoids having to implement every interface member, all the time, that's good too.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
Yes, default interface methods look like a complete mess to me:
Safely update interfaces using default interface methods in C# | Microsoft Docs[^]:
Interfaces can now include static members, including fields and methods. Different access modifiers are also enabled. The additional fields are private, the new method is public. Any of the modifiers are allowed on interface members.
Thankfully, it's restricted to .NET Core 3.0 or later. With no SSRS support in .NET Core / .NET 5, we're sticking with .NET Framework 4.8, so our interfaces shall remain untainted by this abomination. If you're interested, Matt Warren digs into the low-level "behind the scenes" details here: Under the hood of "Default Interface Methods" · Performance is a Feature![^] Oh, and things are set to get even worse in C# 10: [Proposal]: Static abstract members in interfaces · Issue #4436 · dotnet/csharplang · GitHub[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
