| Online Eiffel Documentation

EiffelStudio

# Eiffel for .NET Limitations

## Differences between Eiffel and Eiffel for .NET

### Limitation of Eiffel for .NET in version 5. 5

Most of the Eiffel mechanisms are supported in 5. 5. All missing features listed below are planned for addition in future releases:

- No creation of Eiffel expanded class support
- Partial implementation of generic conformance (same as what was supported up to and including the 4.2 release of the Eiffel development environment).

Eiffel for .NET supports:

- Multiple Inheritance
- Design By Contract
- Exception handling
- Genericity
- Covariance
- Compilation of any existing Eiffel libraries as long as it does not include C externals that call into the Eiffel Software C runtime

### Added to Eiffel and Eiffel for .NET

The following syntax can be used to declare .NET custom attributes on Eiffel entities (features and classes):

    	empty: BOOLEAN is
    		indexing
    			description: "Is Current empty?"
    			attribute: create {OBSOLETE_ATTRIBUTE}.make_obsoleteattribute_1 ("Use `is_empty' instead") end
    		obsolete
    			"Use is_empty instead"
    		do
    			Result := is_empty
    		end

The previous example shows the declaration of the obsolete feature empty . The custom attribute defined by OBSOLETE_ATTRIBUTE is used to ensure that any consumer of the resulting assembly will see the feature as being obsolete. The custom attribute is defined in the indexing clause attribute . The definition consists of a creation expression that creates the custom attribute with the right parameters.

## Differences between Eiffel for .NET and .NET

### Covariance

The CLR (Common Language Runtime) does not support covariance due to the type safety issue that full covariance implies (known as polymorphic CATCALLS in Eiffel). Although very rare, CATCALLS are not suitable to .NET where safety is one of the primary goals.

Eiffel for .NET implements a safe variant of covariance that will always perform a check on the types to avoid a CATCALL. So when a CATCALL is going to be performed a `Invalid Cast Exception' will be raised by the CLR instead of an unexpected behavior as it is currently done in Eiffel.

Another advantage of Eiffel for .NET's implementation of covariance is that it can be easily understood by CLS compliant consumer tools. These tools will actually benefit from the Eiffel for .NET covariance.

### Genericity

The CLR does not support generics at all, so that the following Eiffel for .NET classes:

- LIST [ANY]
- LIST [INTEGER]

will actually be generated as:

- LIST_ANY
- LIST_Int32

Meaning that if one wants to reuse an Eiffel generic class from another language than Eiffel for .NET, one has to use either LIST_ANY or LIST_Int32 .

### Enum types

Eiffel for .NET supports .NET enum types implicitly. From the point of view of Eiffel, they are just considered as expanded classes. The only difference is in the code generation. Eiffel for .NET cannot declare new enum types yet.

### ByRef

Eiffel does not have the notion of `byref' argument passing. At the moment, Eiffel for .NET cannot call nor can it redefine a feature that has a byref argument.