[ale] .NET

[Dennany, Jerome {D177~Roswell}]

>I skimmed the article and it was interesting, but I am still a bit
>confused about something. If I create a set of class in a language that
>supports multiple inheritance (C++, Eiffel, Perl) and use multiple
>inheritance, then according to what you said (and my skimming of the
>article) I would not be able to have interoperability to another
>language (i.e. have C# code make calls to my classes) since I would have
>to run that code "unmanaged".


No, this isn't quite it.  There would be interoperability, but since the CLS does not support multiple inheritance, the 'borders' at which APIs or public interfaces or methods are exposed must be exposed in a manner that is consistant with the CLS.  For example, if you wrote a class library that used genericity or multiple inheritance internally, that would be fine, as long as those classes were not exposed as public.  Perhaps you'd write accessor classes or some wrapper type.

The best example is probably a C# example:  C# allows unsigned ints (through the uint type).  Code written with uints is fine, as long as they are not made public accross language boundaries.  (IE, if a VB.NET program tried to use a method that accepted a uint as a parameter, we'd have problems.  VB.NET does not support the uint type).

Notice that we haven't even touched on managed / unmanaged code yet.  We are just talking about access modifiers (public, private, etc).

So, you can do whatever you want "inside" your code, just be careful that what you expose is CLS compliant.



>So basically I can program so that my code conforms to the Virtual
>Object System model of what an object looks like OR run my code as
>unmanaged and therefore loose the advantages of running under .NET since
>my code is no longer accessible by other languages. Can my "unmanaged"
>code call "managed" code (possibly written in another language)?


I think that we're losing track of what "managed" means - it primarily refers to memory management and garbage collection, not the type system.

But to anwer your question, yes, "unmanaged" code may call "managed" code, and vice versa.  Quite a bit of work has been put into the framework to automatically handle marshalling across the framework boundaries through various interop classes.  COM can call .NET Code, .NET code can call COM code, .NET code can call C-stype APIs, C++ can mix managed and unmanaged code, etc...  Pretty flexible.

>Excuse my ignorance, but I have not read up on .NET as much as I would
>like to.


Of course, take everything I've said with a grain of salt - I don't claim to be the expert in everything, either...



Jerry Dennany