PR# 17029 Please add option to hide secret features .NET

Problem Report Summary
Submitter: peter_gummer
Category: .NET
Priority: Medium
Date: 2010/08/12
Class: Feature Request
Severity: Serious
Number: 17029
Release: 6.6.83873
Confidential: No
Status: Open
Responsible:
Environment: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-au) AppleWebKit/533.17.8 (KHTML, like Gecko) Version/5.0.1 Safari/533.17.8
Synopsis: Please add option to hide secret features .NET

Description
In .NET, secret features appear in the .NET interface generated for each Eiffel class. This is essential for allowing other Eiffel classes that implement those interfaces to access the secret features of their parent classes.

This design is harmful, however, for Eiffel assemblies that are intended to be reused by other .NET languages, because the secret features are visible to their client classes.

There are two scenarios:

Scenario 1: Multiple Eiffel .NET assemblies that need to call each other. For this to work, you need precompiled libraries, and all interfaces within each precompiled library must be "public" so that multiple inheritance can work across assemblies.

Scenario 2: A single Eiffel .NET assembly that is intended to be called only by single-inheritance languages (C#, VB, etc.). For this to work, you just need a normal .NET DLL, and all interfaces within the DLL should be "internal" so that multiple inheritance can work within the assembly while not exposing secret features to C# and VB classes.

There is a clean correspondence between the two scenarios and the kind of library that has to be built. There's no need for a new project option.

So what I propose is this:

(1) When building a .NET precompiled library, the compiler should create "public" interfaces, as it does now.

(2) When building a normal .NET assembly, the compiler should create "internal" interfaces.

Now of course there would be a lot of details to work out to make (2) work well. We would probably still want to have "public" interfaces in (2), with the same names that are currently generated, but minus all of the secret features. This would allow existing C# and VB client code to still compile, except that ill-behaved code that was accessing secret features would fail. This would be a good thing. The code is broken, and the change would raise the alert that it has to be fixed. The "internal" interfaces would have different names (or maybe the same names but a different namespace) so that the Eiffel multiple inheritance mechanism would still work within the assembly.
To Reproduce

										
Problem Report Interactions