Programming Language Independence
Programming Language Independence In order to implement a programming language-independent software bus, you must satisfy two requirements:
The first requirement exists to make our lives as developers easier. If compilers and other development tools can discover the capabilities of a software component prior to runtime, they can perform a variety of compile-time verifications that can both save you time and help you to make your software more robust. For instance, your compiler can verify that a method that is being called on an object actually exists in the object's class. It can also verify that the method is being called with the correct number and type of parameters. Many development tools go even further than this and provide an intelligent prompt that guides you through the construction of a method call. The prompt shows you the available methods on an object and then shows you the type, name , and even a description of each parameter as you enter it. Microsoft calls this Intellisense. The COM solution for describing software components in a programming language-independent way is type libraries. COM includes a language called IDL that developers can use to describe the classes and interfaces that a COM server supports. You then use a compiler called MIDL to turn this IDL into a type library, which contains a standardized, binary representation of the classes, interfaces, and other declarations in the original IDL file. The COM API contains a set of methods that you may use to interrogate the contents of a type library. Many development environments eschew the need for IDL and simply generated the type library directly (VB does this). In most cases, there is a type library for each COM in-process or out-of-process server. Usually, the type library file is embedded within the server although this was not a requirement. COM type libraries canand often aredistributed separately from the server that they describe. The .NET Framework takes the idea of a type library and runs with it. In the .NET world, CLR-compliant compilers are required to generate copious metadata automatically and insert the metadata in the binary files that they generate. There is no separate language for declaring and creating metainformation like IDL. The compiler creates the metadata directly from the code, and, unlike COM, this metadata must reside in the assembly that it describes. .NET metadata includes information that describes all of the types (classes or structures) in the assembly. In addition, the metadata describes the name and type of each field, property, method, and event in those types. For methods and events, the type and directionality (input, output, input and output) of each parameter is described in an assembly's metadata. So far all of the .NET metadata that I have talked about also existed in COM types. The biggest improvement that .NET metadata has over COM type libraries is that .NET metadata also includes important dependency and versioning information that was not stored in COM type libraries. The metadata for each assembly includes the full name of each assembly that it depends on. This means that the CLR can verify that the correct version of each dependent assembly is resident on a host machine at runtime. If the correct version is not present, it can throw an error that clearly indicates that a versioning problem exists. This solves a good portion of the DLL hell problem that plagued the Win32/COM platform. The second programming language independence requirementthat there be a language-neutral interface for calling methodsderives from the fact that different programming languages have different ways of making method invocations. It's not enough to just describe our COM components in a programming language-independent way. We must also be able to call them in a language-independent way. This is complicated by the fact that most programming languages have different calling conventions. For instance, a C/C++ compiler will emit code to push the parameters on the stack in reverse order (from right to left), and the calling function is responsible for cleaning up the stack when the method is done. However, some programming languages push the parameters on the stack in the other order (left to right), and most other programming languages require the called function to clean up the stack. COM solved this problem by defining a binary-level calling convention for COM objects. COM's binary-level calling standard specifies that all method invocations on a COM object be made through interfaces that the object supports. These COM interfaces are an array of function pointers. There is one pointer for each method in the interface. These functions must use the Pascal calling convention, which means that the called function cleans up the stack. Any compiler or development environment that wants either to create or consume COM objects must support this convention. .NET takes a completely different approach. Instead of directly generating executable code, all CLR-compliant compilers generate MSIL code, which is a sort of virtual assembly language. MSIL also defines a standardized representation for objects, which Microsoft calls the VOS. The VOS defines an object model that is shared by all CLR-compliant programming languages. An object model specifies such things as the types of members that a class may have (in .NET, a class may have methods, properties, fields, and events), the possible visibilities of those members (public, private, and so forth), and whether single or multiple inheritance is supported (only single inheritance is supported in .NET). Therefore, whether you're defining an object using Microsoft's Java-like language (C#) or its improved version of VB (VB.NET) or even Cobol or Haskell, a type implemented in any of these languages gets compiled into an equivalent form: a VOS object implemented in MSIL. The advantages of this approach are numerous . Using MSIL and the VOS allows .NET to take programming language independence far beyond what was possible in COM. You can, for instance, create a type in VB.NET and create a subtype that inherits from this type using C#. You can create an exception object and throw it from code written in one language and catch it in code written in a different language. The biggest disadvantage of this approach is that some programming languages (C++ in particular) that have a richer object model than the one supported by the VOS will have to be dumbed down to work with .NET. For example, C++ supports multiple inheritance, but, because the VOS only supports single inheritance, Microsoft's version of C++ for .NET, which is called C++ with Managed Extensions, only supports single inheritance. If you try to use multiple inheritance when you are using the C++ Managed Extensions, the compiler will generate a compilation error. This is not as big a deal as you might think (even though I'm sure some C++/object purists will decry this as a step back) because many people found multiple inheritance to be one of the most confusing aspects of C++. Moreover, although you can only inherit from a single type, you can inherit from multiple interfaces. I explore this more when I discuss the C# language in Chapter 4. Note Keep in mind that you can use the C++ compiler in Visual Studio .NET with or without managed extensions. If you use managed extensions, the compiler generates managed code that runs under the control of the CLR, and you are limited to single inheritance. If you do not use the managed extensions, the compiler generates x86 native code, and you are free to use multiple inheritance to your hearts content. |
 | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 119