| Implementers are encouraged to extend or modify the types specified in this standard to provide additional functionality. Implementers should notice, however, that type names beginning with "System." and bearing the special Standard Public Key are intended for use by the Standard Libraries; such names not currently in use may be defined in a future version of this standard. ANNOTATION This standard is intended to describe a minimum set of programming libraries. It is the explicit intention of the standard that it be extended. However, arbitrary extensions would make it impossible to write portable programs. Therefore, this section explicitly states both legitimate extensions and restrictions. Among the restrictions are that you cannot put new interfaces and virtual methods on existing interfaces, and you cannot add them to abstract classes unless you provide implementations. You cannot take an instance method and make it a virtual method. If this were not forbidden and you compiled against a library that had done this for a method, then your program would be able to successfully override that method. However, the same program would not work on a standard conforming library implementation, because you cannot override instance methods. |
To allow programs compiled against the Standard Libraries to work when run on implementations that have extended or modified the Standard Libraries, such extensions or modifications shall obey the following rules: The contract specified by virtual methods shall be maintained in new classes that override them. New exceptions may be thrown, but where possible these should be subclasses of the exceptions already specified as thrown rather than entirely new exception types. Exceptions initiated by methods of types defined in the Standard Libraries shall be derived from System.Exception. ANNOTATION The second bullet in this section is important to programmers and VES implementers, although of less concern to compilers. It says that it is legitimate (and important) for a VES implementer to throw a new exception, and it should be documented. For example, suppose a class that formerly would take only integers is extended to take floating point numbers too. In this case, current exceptions may need to be extended to include things like floating underflow. |
Interfaces and virtual methods shall not be added to an existing interface. Nor shall they be added to an abstract class unless the class provides an implementation. RATIONALE An interface or virtual method may be added only where it carries an implementation. This allows programs written when the interface or method was not present to continue to work.
Instance methods shall not be implemented as virtual methods. RATIONALE Methods specified as instance (non-static, non-virtual) in this standard are not permitted to be implemented as virtual methods in order to reduce the likelihood of creating non-portable files by using implementation-supplied libraries at compile time. Even though a compiler need not take a dependence on the distinction between virtual and instance methods, it is easy for a user to inadvertently override a virtual method and thus create non-portable code. The alternative of providing special files corresponding to this standard for use at compile time is prone to user error.
The accessibility of fields and non-virtual methods may be widened from that specified in this Standard. NOTE The following common extensions are permitted by these rules. Adding new members to existing types. Concrete (non-abstract) classes may implement interfaces not defined in this standard. Adding fields (values) to enumerations. An implementation may insert a new type into the hierarchy between a type specified in this standard and the type specified as its base type. That is, this standard specifies an inheritance relation between types but does not specify the immediate base type.
RATIONALE An implementation may wish to split functionality across several types in order to provide non-standard extension mechanisms, or may wish to provide additional non-standard functionality through the new base type. As long as programs do not reference these non-standard types, they will remain portable across conforming implementations of the CLI.
|
