On Nov 6, 4:26*pm, Jeroen Mostert <jmost...@xs4al l.nlwrote:
johanatan wrote:
When I first heard about these new features, I was very excited as it
would have (if implemented as I had expected) rendered mimicking
multiple inheritance almost painless in C#. *Unfortunately, due to a
couple limitations of the language, MI is still not attainable (at
least not succinctly).
1 - Interfaces cannot define data (only properties) [This is not a
limitation of 3.5 obviously but being present from day one has caused
ongoing irritation for several years.]
The whole point of an interface is to define a behavioral contract. Fields
have no place in that. What you really want is true multiple inheritance
from classes, not interfaces extended with fields. Interfaces extended with
fields are just abstract classes.
Valid point. But, I see no harm in included data fields in
interfaces.
2 - Extension methods cannot be used to mix in property definitions
(or implement interface methods, or override inherited methods).
Extension methods were never meant to enable any sort of wannabe multiple
inheritance. They serve one particular purpose, which is to enable LINQ.
Anything you can do with extension methods you can do with static methods,
because that's what they are. Extension methods just provide some (vital)
syntactic sugar and overload resolution for this approach. That you are
unable to add new state to classes or override methods is exactly by design.
I understand what the design is-I'm just saying that it is a little
bit to limiting. Do you have any idea why they will not allow
extension methods to implement interfaces (or override methods)?
Another irritation is that the new 'automatic properties' feature
requires that both the getter and the setter have the same
accessibility level (and in practice, this means making a lot more
things 'public' than you'd really like as if you wanted to make both
getter and setter private, there'd be no need for a property at all!).
This is simply false. This works fine:
* *public string Foo { get; private set; }
What *is* true is that automatically implemented properties must define both
* a getter and a setter. Omitting either will get you an abstract property
instead.
Ahh. thanks for that!! That will clean up some of my code.
Back to the MI issue, in my sleep last night an idea occurred to me:
I could use reflection, emit + generics to get MI. I will have a
class such as:
public class Inheritor<T: T
{
}
which I provide a T to dynamically at runtime (using reflection to
create the instance and emit to create the type). The 'target' class
will derive of Inheritor and provide this dynamically type
representing the chain of classes it wants to inherit from.
The type T will consist of:
A <- B <- C <- ... N where I ultimately wanted to derive from A, B,
C, ... N (and where <- represents inheritance).
So, instead of fanning out for MI, we will instead merely have a very
deep one-dimensional hierarchy. ;-)
--Jonathan
