Blurring the Lines Between Interfaces and Abstract Classes
-
Well, interfaces are used widely to implement event handlers of various devices. Usually they define methods for many events: public interface FlyOnTheWallListener onConnect, onDisconnect, onReceive, onConnectionClose, onVendorCompanyWentBroke etc ect. They cover every possible event. I need to respond to two events and will have to implement that interface. It's just how it is sometimes.
Quote:
Well, interfaces are used widely to implement event handlers of various devices. Usually they define methods for many events:
I have no objection to interfaces; I use them a lot, and have even defined a few. For instance, my AnyCSV library, available as a NuGet package from [NuGet Gallery: WizardWrx.AnyCSV 7.0.120.30587](https://www.nuget.org/packages/WizardWrx.AnyCSV/), and as an open source project at [GitHub - txwizard/AnyCSV: Parse ANY CSV String, even X.509 Digital Signature Fields!](https://github.com/txwizard/AnyCSV), relies on one that exposes its capabilities to COM.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
-
Maybe what they needed was a versioning system for interfaces and you lock (or not) your implementation to a given version. I get the motivation, but it seems like they are hacking the language a little too much. Why would someone both with an abstract class?
cheers Chris Maunder
Great, just what we need, IGit and ITfs.
Wrong is evil and must be defeated. - Jeff Ello
-
As I read https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/?utm\_source=Main&utm\_campaign=34ca4f5665-EMAIL\_CAMPAIGN\_2017\_12\_19\_COPY\_01&utm\_medium=email&utm\_term=0\_aa2f642d94-34ca4f5665-227561569&mc\_cid=34ca4f5665&mc\_eid=8087c9508d, the first thing that came to mind is that this new feature, though it's clearly cool and useful, blurs the line between interfaces and abstract classes.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
-
As I read https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/?utm\_source=Main&utm\_campaign=34ca4f5665-EMAIL\_CAMPAIGN\_2017\_12\_19\_COPY\_01&utm\_medium=email&utm\_term=0\_aa2f642d94-34ca4f5665-227561569&mc\_cid=34ca4f5665&mc\_eid=8087c9508d, the first thing that came to mind is that this new feature, though it's clearly cool and useful, blurs the line between interfaces and abstract classes.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
One of the basic missing features of C# / Java is that you cannot inherit from multiple classes. If you could have multiple inheritance, you could get name clashes where different members of the set of base classes have the same member names or even have classes derived from the same lower level base class (this is known as the diamond problem); either of these scenarios could get name clashes, which is why C# does not support it However, other languages (inc C++?) get over it by explicitly stating which base class's method they are accessing. C# already has mechanisms for resolving name clashes in interfaces. So, converting interfaces into faux abstract classes is a simple way of resolving the diamond problem. It's about time this feature came onboard. I can't be the only one who adds comments to their interfaces giving code for typical implementation of the interface methods. Having the code outside of the comments would greatly simplify implementing interfaces. OK, the new feature is a kludge and a back-door way of creating multiple base class inheritance; but it is simple, effective, and backwards compatible.
-
As I read https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/?utm\_source=Main&utm\_campaign=34ca4f5665-EMAIL\_CAMPAIGN\_2017\_12\_19\_COPY\_01&utm\_medium=email&utm\_term=0\_aa2f642d94-34ca4f5665-227561569&mc\_cid=34ca4f5665&mc\_eid=8087c9508d, the first thing that came to mind is that this new feature, though it's clearly cool and useful, blurs the line between interfaces and abstract classes.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
-
As I read https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/?utm\_source=Main&utm\_campaign=34ca4f5665-EMAIL\_CAMPAIGN\_2017\_12\_19\_COPY\_01&utm\_medium=email&utm\_term=0\_aa2f642d94-34ca4f5665-227561569&mc\_cid=34ca4f5665&mc\_eid=8087c9508d, the first thing that came to mind is that this new feature, though it's clearly cool and useful, blurs the line between interfaces and abstract classes.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
One of my favorite things about C# as opposed to C++ is that they don't get wrapped around the axle over adding useful features that piss off the language dilettantes. This is a useful feature. It lets you implement an interface change piecemeal, rather than forcing you to implement the change in one great steaming pile. You can even have the default implementation perform an assert to help ensure you've caught all cases. The C++ folks would flagellate themselves for years over this, there would be dozens of half-baked implementations with wildly conflicting implementations, and when the standard was finally issued, no one would care.
Software Zen:
delete this; -
Quote:
David A. Gray wrote: After all, generics are, for all practical purposes, abstract classes. I really don't agree with that.
Please clarify. 1) You cannot directly implement a generic class. 2) The class provides default implementations of its methods to all instances. How, then, is a generic class anything more, nor less, than a specialized type of abstract base class?
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
Sure.
David A. Gray wrote:
- You cannot directly implement a generic class.
Of course you can. The only constraint is the existence of one or more assigned types, that may or may not be resolved before runtime. I guess if you had a generic abstract class you would need to provide an implementation, but that's because it's abstract, not because it's generic.
David A. Gray wrote:
- The class provides default implementations of its methods to all instances.
I must be misunderstanding this, because even in terms of fundamental class operations this is false, as it conflates inheritance with instantiation.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
One of my favorite things about C# as opposed to C++ is that they don't get wrapped around the axle over adding useful features that piss off the language dilettantes. This is a useful feature. It lets you implement an interface change piecemeal, rather than forcing you to implement the change in one great steaming pile. You can even have the default implementation perform an assert to help ensure you've caught all cases. The C++ folks would flagellate themselves for years over this, there would be dozens of half-baked implementations with wildly conflicting implementations, and when the standard was finally issued, no one would care.
Software Zen:
delete this;C# just tries to catch up with Java 8. Java 8 had this feature since 2014: [https://dzone.com/articles/interface-default-methods-java\](https://dzone.com/articles/interface-default-methods-java)
-
C# just tries to catch up with Java 8. Java 8 had this feature since 2014: [https://dzone.com/articles/interface-default-methods-java\](https://dzone.com/articles/interface-default-methods-java)
Yes, yes, Jim Gosling is God, Bill Gates is the anti-Christ, and we're all fools for using Micro$haft products. Now that's cleared up, your point?
Software Zen:
delete this; -
Sure.
David A. Gray wrote:
- You cannot directly implement a generic class.
Of course you can. The only constraint is the existence of one or more assigned types, that may or may not be resolved before runtime. I guess if you had a generic abstract class you would need to provide an implementation, but that's because it's abstract, not because it's generic.
David A. Gray wrote:
- The class provides default implementations of its methods to all instances.
I must be misunderstanding this, because even in terms of fundamental class operations this is false, as it conflates inheritance with instantiation.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
Quote:
You cannot directly implement a generic class.
I need to rephrase that; you cannot instantiate an abstract class.
Quote:
- The class provides default implementations of its methods to all instances
This, too, needs rephrasing; when I create an abstract class, I usually define default implementations of all methods, any of which inheritors are free to override.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
-
One of my favorite things about C# as opposed to C++ is that they don't get wrapped around the axle over adding useful features that piss off the language dilettantes. This is a useful feature. It lets you implement an interface change piecemeal, rather than forcing you to implement the change in one great steaming pile. You can even have the default implementation perform an assert to help ensure you've caught all cases. The C++ folks would flagellate themselves for years over this, there would be dozens of half-baked implementations with wildly conflicting implementations, and when the standard was finally issued, no one would care.
Software Zen:
delete this;Quote:
This is a useful feature. It lets you implement an interface change piecemeal, rather than forcing you to implement the change in one great steaming pile. You can even have the default implementation perform an assert to help ensure you've caught all cases.
Thanks for being the first to show a worthy use case for default implementations of interfaces.
Quote:
he C++ folks would flagellate themselves for years over this, there would be dozens of half-baked implementations with wildly conflicting implementations, and when the standard was finally issued, no one would care.
This I suspect is largely, if not entirely, the result of C# being the responsibility of a single vendor, Microsoft, who has enough muscle to call the shots unequivocally. In contrast, the C++ standard is the work of a committee composed of people from competing vendors, who are motivated by those affiliations to say and do things that favor the people who pay their salaries. The result is compromises and endless delays.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
-
One of the basic missing features of C# / Java is that you cannot inherit from multiple classes. If you could have multiple inheritance, you could get name clashes where different members of the set of base classes have the same member names or even have classes derived from the same lower level base class (this is known as the diamond problem); either of these scenarios could get name clashes, which is why C# does not support it However, other languages (inc C++?) get over it by explicitly stating which base class's method they are accessing. C# already has mechanisms for resolving name clashes in interfaces. So, converting interfaces into faux abstract classes is a simple way of resolving the diamond problem. It's about time this feature came onboard. I can't be the only one who adds comments to their interfaces giving code for typical implementation of the interface methods. Having the code outside of the comments would greatly simplify implementing interfaces. OK, the new feature is a kludge and a back-door way of creating multiple base class inheritance; but it is simple, effective, and backwards compatible.
Quote:
t's about time this feature came onboard. I can't be the only one who adds comments to their interfaces giving code for typical implementation of the interface methods. Having the code outside of the comments would greatly simplify implementing interfaces. OK, the new feature is a kludge and a back-door way of creating multiple base class inheritance; but it is simple, effective, and backwards compatible.
Well stated! ;)
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
-
Quote:
You cannot directly implement a generic class.
I need to rephrase that; you cannot instantiate an abstract class.
Quote:
- The class provides default implementations of its methods to all instances
This, too, needs rephrasing; when I create an abstract class, I usually define default implementations of all methods, any of which inheritors are free to override.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
Great, so now we've come to consensus as to what we're saying about abstract classes, which brings us back around to where the point of contention is: I don't agree that generic classes are anything at all like abstract classes. The most basic way I can present that thought process is this: An abstract class describes a contract, a concrete class fulfills the contract, and a generic utilizes a contract. An abstract class presents an "is a" relationship to inheriting types; a generic presents a "operates on" relationship to assigned types. Take List as an example. Trying to compare an instance of List to an instance of type T is pointless; they are completely different things. What List does, though, is provide a container and enumeration strategy for instances of type T; or operations, if you will. I think that's a far cry from "a specialized type of abstract base class".
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
Great, so now we've come to consensus as to what we're saying about abstract classes, which brings us back around to where the point of contention is: I don't agree that generic classes are anything at all like abstract classes. The most basic way I can present that thought process is this: An abstract class describes a contract, a concrete class fulfills the contract, and a generic utilizes a contract. An abstract class presents an "is a" relationship to inheriting types; a generic presents a "operates on" relationship to assigned types. Take List as an example. Trying to compare an instance of List to an instance of type T is pointless; they are completely different things. What List does, though, is provide a container and enumeration strategy for instances of type T; or operations, if you will. I think that's a far cry from "a specialized type of abstract base class".
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
Quote:
Take List as an example. Trying to compare an instance of List to an instance of type T is pointless; they are completely different things. What List does, though, is provide a container and enumeration strategy for instances of type T; or operations, if you will. I think that's a far cry from "a specialized type of abstract base class".
A generic type, such as
Listprovides a generic (abstract!) implementation of aList, which has well-defined properties and methods, such asAdd,Remove,Sort, andCount, whereas a concrete instance, such asListimplements the genericListbehaviors for a list of integers. Furthermore, you cannot instantiate a List, any more than you can instantiate any other abstract base class, such asSystem.IO.Stream; you must instantiate aList, whereOfTypeis some concrete type.David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
-
Quote:
This is a useful feature. It lets you implement an interface change piecemeal, rather than forcing you to implement the change in one great steaming pile. You can even have the default implementation perform an assert to help ensure you've caught all cases.
Thanks for being the first to show a worthy use case for default implementations of interfaces.
Quote:
he C++ folks would flagellate themselves for years over this, there would be dozens of half-baked implementations with wildly conflicting implementations, and when the standard was finally issued, no one would care.
This I suspect is largely, if not entirely, the result of C# being the responsibility of a single vendor, Microsoft, who has enough muscle to call the shots unequivocally. In contrast, the C++ standard is the work of a committee composed of people from competing vendors, who are motivated by those affiliations to say and do things that favor the people who pay their salaries. The result is compromises and endless delays.
David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
David A. Gray wrote:
he C++ standard is the work of a committee composed of people from competing vendors, who are motivated by those affiliations
While that is certainly true to some extent, it's not the whole issue. I knew a couple of people involved with the standards committee, and very smart folks. Both were very motivated by abstract principles, language esthetics, and compiler implementation concerns. Their assumption was that by satisfying these motivations, usefulness to their target audience (working stiffs like you and I) would just naturally fall out. Sometimes that has been true. For me, C# on the other hand seems to acquire features that say "that just might be useful" on a frequent basis. Who cares if it's just syntactic sugar? If it makes it easier for me to write clean, quality code, then it's useful. If this happens because of the Microsoft monoculture, so be it. I'm a programmer to pay the bills, not to worship at the altar of someone's polytheistic dogma.
Software Zen:
delete this; -
One of my favorite things about C# as opposed to C++ is that they don't get wrapped around the axle over adding useful features that piss off the language dilettantes. This is a useful feature. It lets you implement an interface change piecemeal, rather than forcing you to implement the change in one great steaming pile. You can even have the default implementation perform an assert to help ensure you've caught all cases. The C++ folks would flagellate themselves for years over this, there would be dozens of half-baked implementations with wildly conflicting implementations, and when the standard was finally issued, no one would care.
Software Zen:
delete this;Gary Wheeler wrote:
This is a useful feature. It lets you implement an interface change piecemeal, rather than forcing you to implement the change in one great steaming pile
You are right! Making a tiny mod to an existing interface means every use of the interface in dozens of locations needs to be updated. Having a default method would mean that no changes to existing code would be needed. Only code that wanted to exploit the new feature(s) need implement the new method(s). Of course, you can avoid this already by creating a new interface that inherits the old one and just converting occasions that need the new methods from the old interface name to the new interface name.
-
Quote:
Take List as an example. Trying to compare an instance of List to an instance of type T is pointless; they are completely different things. What List does, though, is provide a container and enumeration strategy for instances of type T; or operations, if you will. I think that's a far cry from "a specialized type of abstract base class".
A generic type, such as
Listprovides a generic (abstract!) implementation of aList, which has well-defined properties and methods, such asAdd,Remove,Sort, andCount, whereas a concrete instance, such asListimplements the genericListbehaviors for a list of integers. Furthermore, you cannot instantiate a List, any more than you can instantiate any other abstract base class, such asSystem.IO.Stream; you must instantiate aList, whereOfTypeis some concrete type.David A. Gray Delivering Solutions for the Ages, One Problem at a Time Interpreting the Fundamental Principle of Tabular Reporting
o.O List is a concrete type. It is not abstract. The fact that you need to pass in a generic parameter makes it no less concrete. I do not need to write a new implementation for List, or List, or List>, because List is concrete already. Otherwise you'd need to write an implementation for every type T you might pass in, which would, IMO, completely defeat the purpose of generics.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor