I've often wanted this feature for building custom asp.net server controls.
When I need to make a common modification to 23 of the standard controls
included in the vs.net toolbox (framework itself) I found myself
copy-and-pasting the same code into 23 inherited classes that represent each
control. I didn't like that because if my original code had a typo or
defect, I had to go and re-copy-and-paste all those others and it got to be
so time consuming that I actually found it much faster and easier to create
my own base class that inherits webcontrol and then all of the 23 custom
control inherit that. Then, I re-implement all of the 23 controls in
ASP.NET from scratch. My productivity is much higher now.
I could not find a way to both inherit from the original control and from my
common base class which would have only contained the addition "common"
functionality (not inherited from webcontrol) for all 23 classes. I don't
want to use the "composition" technique, either. Because that wouldn't have
solved my problem without all the code duplication and there is less
productivity, IME (in my experience).
So I'm highly productive now but have reimplemented the controls from
scratch (which many may argue is less efficient because I'm not benefitting
from other people's work). Let them argue. They aren't the ones losing
productivity over this issue. The button control is a prime example of why
I want to create it from scratch, it hardcode the type as a submit and
provides no way to override it without inserting an additional attribute of
type=button and so, to provide a way to specify what type of button it is, I
had to create it from scratch. So I couldn't inherit from the base class
anyway, and reuse it, not without having this problem.
They say that MI is evil. Maybe many in the C++ world don't understand it
and they abuse it. But I've never had problems with it. Again, with
Eiffel, it is very well implemented and hardly causes problems. So I don't
see why it would be a problem in the CLR except that "common-denominator"
programmers will likely abuse it. Well, mixed unsafe code in C# can be
abused also and that didn't stop them from putting it there as are many
other features that can be abused but are still there and aren't being
abused. In the end, the prevailing argument is that it would hurt the
performance of the JIT process. I can buy that, but it can always be
optimized.
Microsoft has many of the smartest people in the world working there, I find
it hard to believe that can't find a good solution for this problem but,
Anders, will probly never allow it and that it the true reason. When the
designer is inherently biased against a feature, there is a good chance it
won't ever be more than considered and always remain and -10 in the hole
(they use a point system for determining what features to add to the
language and always starts at -10 and works its way up or not).
Thanks,
Shawn
"Bret Pehrson" <br**@infowest.com> wrote in message
news:40***************@infowest.com...
Since managed code (C++/C#/etc.) doesn't support multiple inheritance,
does anyone have a suitable work-around? To me, this is a *serious* limitation
of the .NET subsystem.
I'm aware of *interfaces*, but they are for the *USER* of the class, not
the *IMPLEMENTOR*. I'm also aware of adding multiple classes to a class and
then creating wrappers (more of a HAS-A implementation than IS-A), but that is
tedious and again is more for the class user and doesn't support
polymorphism.
Here is an example:
Suppose I have a non-trivial class that has no interface (it is purely a
functional component). There is *no way* to add an interface (ala forms)
to that component without changing the base class itself.
--
Bret Pehrson
mailto:br**@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>
