By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,206 Members | 1,035 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,206 IT Pros & Developers. It's quick & easy.

Extension methods almost allow multiple inheritance via mixins (butnot quite)

P: n/a
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.]
2 - Extension methods cannot be used to mix in property definitions
(or implement interface methods, or override inherited 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!).

Any comments? (or other suggestions or workarounds [besides containment
+wrappers (which I already have a macro to generate). (obviously, the
generated wrapper approach is a maintenance nightmare and produces
many more lines of code to read than I'd prefer)])

--Jonathan
Nov 6 '08 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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.
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.
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.

--
J.
Nov 7 '08 #2

P: n/a
On Nov 6, 4:26*pm, Jeroen Mostert <jmost...@xs4all.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
Nov 7 '08 #3

P: n/a
On Nov 7, 7:44*am, johanatan <johana...@gmail.comwrote:
>
public class Inheritor<T: T
{

}
Well C# will not accept this, so I must find another workaround.
Maybe the solution will have to be done completely at runtime (even
the leaf class) using reflection+emit. That's a little bit
unfortunate as the code will be less easy to read.

--Jonathan
Nov 7 '08 #4

This discussion thread is closed

Replies have been disabled for this discussion.