I've been thinking about static interfaces, and I think they would be really useful for software which uses reflection to identify and assemble components. Currently I find myself having to design around this limitation with unnecessary factories or by enforcing conditions at runtime (like checking for methods and throwing exceptions if they aren't present).
It would be great if the following was possible:
foreach (var type in Assembly.GetExecutingAssembly().GetTypes().Where(t => t is IStaticInterfaceType))
(type as IStaticInterfaceType).StaticMethod();
This could be used for singleton patterns, initialization methods, registration methods, constructor contracts, or any number of other things.
I don't know how much overhead this would introduce, but perhaps this would be possible by making every class have its own corresponding Type. This type would be derived from Type and would implement the static interfaces for the type.
This would allow for much safer use of reflection (which is a brilliant tool for keeping things modular and for reducing code bulk).
Johannes Moersch commented
Here are some other feature requests that are encompassed by static interfaces:
Zachary Patten commented
Static interfacing would completely change how people use generic types. They could be used to have classes inherit from an interface without adding the interface to the class declaration.
public static-interface Algebra<T>
static T QuadraticFormula(T a, T b, T c);
public static class Implementer_double : Algebra<double>
// ... implementation for "QuadraticFormula" method ...
public class SystemSolver<T> where T has Algebra<T>
// solves a system of equations by using "QuadraticEquation" function
// IN MAIN:
SystemSolver<double> systemSolver = new SystemSolver<double>();
The type "double" does not inherit from "Algebra", but because the interface is static, it cannot involve polymorphism (overriding). The static functions within the "static-interface" would have to be added to either the vtable or some table (for runtime handling), but this functionality should be relatively easy to implement.
(1) generic mathematics
(2) clean up many factory/conversion implementations (and other common utilities)
(3) allow developers to easily adapt code form other libraries that cannot be altered
(4) would provide an alternative for achieving multiple inheritance like functionality
(5) would allow even faster generic usage for the OCD optimizers (like me)
And these are just a few reasons I came up with in 2 minutes...
MICROSOFT! ADD THIS FEATURE!!!