|
|
Sure, except that you can inherit multiple interfaces and you still can't instantiate one without an implementation.
Architecturally, they still have highly different uses.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Quote: Sure, except that you can inherit multiple interfaces and you still can't instantiate one without an implementation.
Depending on how it is defined, it is possible to inherit an abstract class. Two cases in point are List<T> and Dictionary<object,object>. After all, generics are, for all practical purposes, abstract classes.
Quote:
Architecturally, they still have highly different uses.
About that, I agree, so why muddy the waters with this new construct that is half interface and half virtual method?
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
David A. Gray wrote: After all, generics are, for all practical purposes, abstract classes.
I really don't agree with that.
I think in general the purpose of really surface-level default implementations give you options for interacting with those implementations or to give a default error. That's mostly it, or at least that's all I'd use it for. I don't see that as muddying.
I think it will result in much more composable code, and that's a valid purpose.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
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: 1) 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: 2) 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: 2) 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<t> as an example. Trying to compare an instance of List<t> to an instance of type T is pointless; they are completely different things. What List<t> 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<t> as an example. Trying to compare an instance of List<t> to an instance of type T is pointless; they are completely different things. What List<t> 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 List<T> provides a generic (abstract!) implementation of a List, which has well-defined properties and methods, such as Add, Remove, Sort, and Count, whereas a concrete instance, such as List<int> implements the generic List behaviors for a list of integers. Furthermore, you cannot instantiate a List<t>, any more than you can instantiate any other abstract base class, such as System.IO.Stream; you must instantiate a List<OfType>, where OfType is 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<t> 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<int>, or List<myclass>, or List<action<myotherclass>>, because List<t> 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
|
|
|
|
|
Quote: Sure, except that you can inherit multiple interfaces and you still can't instantiate one without an implementation.
Depending on how it is defined, it is possible to inherit an abstract class. Two cases in point are List<T> and Dictionary<object,object>. After all, generics are, for all practical purposes, abstract classes.
Quote:
Architecturally, they still have highly different uses.
About that, I agree, so why muddy the waters with this new construct that is half interface and half virtual method?
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
|
|
|
|
|
Quote: 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?
That was my point.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
so maybe sealed methods on the interface? They are part of the interface but can't be implemented.
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|
I prefer a sealed interface. It ends in much less work 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
and unsealed wine or scotch
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|
Great, just what we need, IGit and ITfs.
|
|
|
|
|
Is this the programming technique video that Emily Ratajkowski was in?
Explorans limites defectum
|
|
|
|
|
|
No, it's a short article; there is a picture or two, but no video.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
I weep for the world when you can't even make a good risque innuendo anymore...
Explorans limites defectum
|
|
|
|
|
I'm sure you can. You just haven't.
|
|
|
|
|
No, you are...
Explorans limites defectum
|
|
|
|
|
Interface default methods is a pointless "feature".
Abstract classes are infinitely more useful than interfaces. I rarely use/create interfaces (I usually only use them when some .net feature demands it, such as IDisposable or INotifyPropertyChange. In either case, you still have to implement the abstract methods/properties, or the interface methods.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Quote: Interface default methods is a pointless "feature".
Thank you for getting my point.
Quote: Abstract classes are infinitely more useful than interfaces.
Absolutely!
Quote: I rarely use/create interfaces (I usually only use them when some .net feature demands it, such as IDisposable or INotifyPropertyChange. In either case, you still have to implement the abstract methods/properties, or the interface methods.
My personal exception to that rule is IComparable<t>, which I frequently implement, so that I can make collections of classes sortable and searchable.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
