StandardizationMicrosoft worked hard to push the CLI and C# through standardization, and they did so with record results. I cannot think of a programming language or platform that made it from the Version 1 release to an international standard faster than C# and the Common Language Infrastructure (CLI). This is all due to Microsoft playing their cards correctly and not for aught. Standards OrganizationsMicrosoft originally submitted the CLI and the C# programming language to the European Computer Manufacturers Association (ECMA) for standardization. In December of 2002, the second edition of ECMA-335 Common Language Infrastructure (CLI) became a standard. The C# programming language became ECMA-334 simultaneously. Because of the close relationship of ECMA with the International Standards Organization (ISO), C# and the CLI finished their fast-track standardization in April of 2003. The CLI is now ISO 23271:2003, and C# has become ISO 23270:2003. So when working with the CLI and C#, you can be assured you are working with a real standard from a real standards body and not some unheard of organization. Microsoft's ISO standardization is an all-around win, especially in large organizations (such as governments) that may require the use of ISO programming languages. I do not believe that Microsoft would want to suffer the international humiliation of retracting a standard, even if ISO would allow them to. ISO standardization allows for other implementations of the CLI and C# standards to be created and used with great confidence and freedom. But this then begs the question, "What exactly is in the standards?" What Is in the StandardsNow that I am getting technical, it is time to start defining and using the technical terms associated with the standards. Figure 2-1 shows the different parts of the standards and how they interact. Figure 2-1. The CLI Standard.[View full size image]  Figure 2-2. Type Classification.Table 1.1 in Chapter 1 lists just a few languages that support the CLS and are freely available for Open Source, but there are numerous other CLS languages available that are not listed in this table. CLS takes programming language integration a step further. Existing technology such as CORBA or COM allowed language interoperation to a point, but the CLS allows all languages access to the CLI base framework, easy language interoperation, and cross-language inheritance. Miguel de Icaza from Ximian's Mono project put it best:We [Ximian] were interested in the CLR because it solves problems that we face every day. The Java VM did not solve this problem.The .NET Framework: Using the ECMA Standards: An interview with Miguel de Icaza, MSDN My interest in .NET comes from the attempts that we have made before in the GNOME project to achieve some of the things .NET does:
Peeking under the Lid of Open Source .NET CLI Implementations, DevX This language agnostic approach truly sets the CLI apart from any other programming platform and provides a very rich set of APIs to all languages.C# is the language of choice when using the CLI because it is a standard and shows off most (but not all) of the CLI functionality. For a good book on just the syntax and semantics of the C# language, see A Programmer's Introduction to C# (Second Edition) by Eric Gunnerson, ApressI like Eric's book because he sticks to what the C# language can do without sidetracking into other parts of the .NET framework. When I want to know if a particular feature, such as defaulting optional function parameters, is supported by C#, I do not want a book that covers everything from ASP.NET in C# to XML in C#. While those parts of the framework are essential to understand, they are also broad and apply to all CLS-compliant languages.http://www.hutteman.com/weblog/2003/04/06-56l), illustrates this perfectly as he observes on his blog, and I quote:It's interesting how C# and Java seem to be playing leapfrog. C# started out with many of Java's features and some useful improvements of its own, and now Java is taking a number of C# features like attributes, enums, foreach and autoboxing, and adds some more like generics, static imports, and extendable enums.Enums are something that are long overdue for Java, and their implementation in JDK 1.5 seems extremely powerful… .NET 2.0 will also add support for generics. From what I heard, they will leapfrog Java again on that one by allowing that type-information to be available at run-time as well. I seem to remember reading somewhere that Java's generics will be compile-time only. At run-time, a Collection<String> in Java will look like any other Collection…Hopefully, in the near future, a language will support exceptions to my liking in a more robust way. In my opinion, no language does a good job of simplifying exception handling, but Java probably comes a little closer to this than other languages. A tool called CLRxLint (http://www.software4net.com/products/clrxlintl) from software4net does provide Java-like checked exceptions for CLS-compliant languages, but it's still not an ideal solution. This awkward support for exceptions is why so many people punt and just catch the base Exception class and get themselves into trouble. It would be nice to be able to use reflection to find out what exceptions you should expect to be thrown. For more insight on this issue, see the interview (http://www.artima.com/intv/handcuffsPl) with Anders Hejlsberg (the leader of the C# design team), Bruce Eckel, and Bill Venners, where Anders discusses his reasoning for not using checked exceptions. What Is Not in the StandardsIf you peek ahead at Figure 2-3, you will see how Microsoft's implementation of the CLI is a lot more than just what they have chosen to standardize. Now that we know what is in the standards, we should look at what is not in the standards. Some of the most innovative parts of Microsoft's CLR (including ADO.NET, ASP.NET & Windows Forms) are not part of the CLI or C# standard. Windows Forms are a great advancement in rapid development and ease of use over traditional MFC User Interface programming. I personally believe that Windows Forms and User Interfaces in general are probably the most difficult things to make platform-independent. Keeping a consistent look and feel is not adequately accomplished in Java's Swing, TCL/TK, GTK+, or any other toolkit I have seen. After just playing with a UI for a few seconds, I can tell what was used to create the UI. Although users do not explicitly understand the differences, it has been my experience that users subconsciously know when a UI does not quite fit with the paradigm of the operating system they prefer. ADO.NET is another non-standard that, once you have used it, is hard to live without. ADO.NET mixes XML and data access very well, making n-tier systems much easier to implement. Unfortunately, the non-standardization of ADO.NET truly hinders pure Web service development because datasets cannot be passed between .NET Web services and other Platforms (like Java's) Web service implementations. It is this author's opinion that Microsoft would benefit from standardizing ADO.NET because then it could be used more frequently to exchange data between programming platforms. ASP.NET is also a fairly large innovation that is not standardized. ASP.NET introduces the unique idea of using server-side controls, which gives the programmer a closer programming model to a thick client. This makes for faster Web UI coding and, with the help of vendor components, a richer UI for the client. Figure 2-3. Microsoft's Common Language Runtime.[View full size image]  |
لطفا منتظر باشید ...
