From COM to .NET

[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.

[Brad Quinn]

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.

-----Original Message-----
Hi all,

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

Thanx,
Adrian.
.

[Adrian Herscu]

"Brad Quinn" <br***********@hotmail.com> wrote in message
news:22*****************************@phx.gbl...

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.

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.

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.

-----Original Message-----
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.
.

[Kirk]

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

-----Original Message-----
Hi all,

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

Thanx,
Adrian.
.

[Adrian Herscu]

"Kirk" <mc**************@hotmail.com> wrote in message
news:00****************************@phx.gbl...

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.

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?
Anyway, may or may not be the right answer, but ....

Kirk

-----Original Message-----
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.
.