|
|
I also thought last night about :
A Closure
Explorans limites defectum
|
|
|
|
|
A Religion.
Spaces or tabs? Linux or Windows? ...
|
|
|
|
|
A Schism of programmers?
Explorans limites defectum
|
|
|
|
|
It really depends upon their particular breed (e.g., a flock of geese but a murder of crows).
One that fits well is "An Infestation of Agile Developers".
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
APL programmers: a confusion
C or C++ programmers: a corruption
C# or Java programmers: a delegation
FORTRAN programmers: a computation
COBOL programmers: a company
BASIC programmers: an asylum
LISP programmers: a list (of course)
Pascal programmers: a school
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Can't believe no one threw in a "Heap". 
|
|
|
|
|
The responses are very funny unfortunately someone might take this seriously so we need to let identity stay in the political area of our society and not let it enter our profession.
Such a sad state but it is what it is for now
BTW I would prefer a Dorkal 
Buckrogerz
|
|
|
|
|
A Hive. Bugs swarm out of hives...
|
|
|
|
|
Hmmm... what about a Bitset?
Explorans limites defectum
|
|
|
|
|
A collection of good programmers could be a cluster.
A collection of bad programmers would be a clusterf**k.
|
|
|
|
|
How about a Byte? Each one in a group is a Bit. If there are more than 8 in the group, it's a Word of Software Engineers, more than 16 is a DoubleWord (or DWord), more than 32 is a QuadWord (or QWord), etc.
|
|
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
