From COM to .NET

  • Thread starter Thread starter Adrian Herscu
  • Start date Start date
A

Adrian Herscu

Hi all,

During the COM age, Microsoft's policy was against implementation
inheritance.
Now, it turns 180 degrees and all the .NET Framework relies heavily on
implementation inheritance.
What's changed?

Thanx,
Adrian.
 
Good question.

Does the Framework ~really~ rely heavily on implementaion
inheritance? Sure everything derives from object, but I
mean in a deep or wide way. I think that you'll find the
implementaion inheritance to be pretty light-weight
compart to something like MFC.

It might be interesting (or not) to compare how often a
class (in the framework) derives from another class
and/or how many interfaces it implements.

I guess one thing that has changed is there is support
for interface inheritance in the Common Language
Runtime. If I'm not mistaken (and I may be) there was no
II support in the language (VB).

Implementation inheritance has a certain set of
challenges associated with it. Especially when changes
are made to the base classes. Now Microsoft has to be
careful when it considers changing it's base classes
because we'll all have to live with it.

Hope you get some better answers that this one.
 
Brad Quinn said:
Good question.

Does the Framework ~really~ rely heavily on implementaion
inheritance? Sure everything derives from object, but I
mean in a deep or wide way. I think that you'll find the
implementaion inheritance to be pretty light-weight
compart to something like MFC.
Click to expand...

What exactly do you mean by saying "deep or wide way"?
I'm talking about the visibile part (the thing that .NET programmers use in
their everyday life). And it is build on the implementation inheritance
concept.
 
If I would to offer my guess (which i suppose I am now
doing) it would be that MS limited COM's ability to to
implementation inheritance simply because the they needed
something that would work across multiple languages.
There was no core framework that all languages derived
from, so it would have been nearly impossible to allow
implementation inheritance between, say, VB and FoxPro, or
Delphi and C++ through the COM layer.

One of the great things about everyong compiling to a
single language (msil) is that we can now enforce rules
that all languages must follow and this opens the door to
allow implementation inheritence.

Anyway, may or may not be the right answer, but ....

Kirk
 
Kirk said:
If I would to offer my guess (which i suppose I am now
doing) it would be that MS limited COM's ability to to
implementation inheritance simply because the they needed
something that would work across multiple languages.
There was no core framework that all languages derived
from, so it would have been nearly impossible to allow
implementation inheritance between, say, VB and FoxPro, or
Delphi and C++ through the COM layer.

One of the great things about everyong compiling to a
single language (msil) is that we can now enforce rules
that all languages must follow and this opens the door to
allow implementation inheritence.
Click to expand...

So now you can use implementation inheritance relationship
between types belonging to different applications/libraries,
written in different languages, but compliant with .NET platform.

Where is the benefit by using the implementation inheritance
model (the"new" tech.), against the using of object composition,
delegation and call-backs model (the "old" tech.).

The previous reply (Brad), says:
"Implementation inheritance has a certain set of
challenges associated with it. Especially when changes
are made to the base classes. Now Microsoft has to be
careful when it considers changing it's base classes
because we'll all have to live with it."

What is the Microsoft answer for that?
 
Back
Top