|
2002 03 02 Saturday dyree(e) in K
 | what he doesn't like: |
| [..] Examples include: |
| the presence of overloading, a vanity mechanism that brings nothing to the semantic power of an O-O language, but hampers readability and complicates everyone’s task; |
| lack of support for multiple inheritance, except (Java style) for “interfaces”; |
| the C++ mechanism for constructors (based on using a single name for all constructors for a class, disambiguating clashes through an irrelevant property, type signatures, and forcing the initialization of an object to go through the initialization procedures for all ancestor types); |
| novariance of routine arguments and results; |
| the difficulty of keeping a clear separation between member names and member values (to support, for example, renaming as in Eiffel). |
| I understand the source of these problems: the .NET designers are not responsible for C++. But what these decisions mean is, in many cases, forcing a complicated solution where simple ones are readily available. |
| heh: |
| Too bad; as anyone who has observed Java and Smalltalk programmers knows, removing multiple inheritance from an O-O language leads programmers to emulate it manually through the kind of tricks that should not be further described in a family-oriented column. |
| By the way, please do not pay attention to anyone who tells you that multiple inheritance is inherently “bad” or “dangerous” or “messy”. There is one and only one reason Java and .NET don’t have MI: it makes dynamic class loading far more difficult to implement. Every other reason is a red herring. (Harangue mode off.) |
| elements: |
| At the center of the .NET framework is an object model, called the VOS (Virtual Object System); |
| Based on the object model, .NET offers a virtual machine, the Common Language Runtime |
| One of the distinctive traits of the virtual machine is that, unlike its Java counterpart, it does not provide an interpreter: MSIL is meant for on-the-fly compilation to machine code the first time each MSIL unit is executed. This is also known as “Jitting the code”, where “Jit” stands for Just In Time compilation. Here .NET draws the lessons of the Java experience (familiar enough to anyone who has ever seen the dreaded message “Starting Java” show up in the browser) by putting performance concerns at the heart of design goals. The results are impressive: we have seen no difference between the speed of .NET-generated Eiffel# applications and that of code generated through our standard compiler (which produces machine code through C). The tradeoffs are clear: Java’s interpreter-oriented design (where JIT compilers are an afterthought) has fostered portability; .NET’s design has put run-time performance at the top of the design goals. |
|
.
.
.
.
.
home
.
english
.
deutsch
.
siteindex
.
.
.
.
.
.
.
.
.
.
.
.
.
.
|