The idea that the concept of System.Object could be replaced by interfaces that, as a rule, all classes implement has been mentioned a few times on this question. While I think the idea is valid, in the end I would say that it doesn't buy you anything. Even if such interfaces existed, the question would still remain of how the compiler would actually ensure that classes implemented those interfaces.
Below is some example code where I try to explore a hypothetical situation where there is no System.Object type and how the implementation under the hood as well as usage of those interfaces might look.
// let's start off by defining interfaces to describe the various methods that are currently available from the System.Object class
public interface IEquatable
{
bool Equals(IEquatable other);
}
public interface IHashCodeGenerator
{
int GetHashCode();
}
public interface ITypeIdentifiable
{
Type GetType();
}
public interface IConvertibleToString
{
string ToString();
}
// This guy throws a wrench into things, because we can't privately (or "protectedly") implement an interface.
// This is discussed further below on the MyClass.MemberwiseClone method.
public interface IMemberwiseCloneable
{
}
// This class simply encapsulates similar functionality found within the System.Object class
public static class ClrInternals
{
[MethodImpl(MethodImplOptions.InternalCall)]
internal static extern bool Equals(IEquatable objA, IEquatable objB);
[MethodImpl(MethodImplOptions.InternalCall)]
internal static extern int GetHashCode(IHashCodeGenerator hashGenerator);
[MethodImpl(MethodImplOptions.InternalCall)]
internal static extern Type GetType(ITypeIdentifiable typedInstance);
[MethodImpl(MethodImplOptions.InternalCall)]
internal static extern IMemberwiseCloneable MemberwiseClone(IMemberwiseCloneable original);
}
// let's say that as a rule the compiler implicitly makes all classes implement these interfaces
class MyClassExampleA : IEquatable, IHashCodeGenerator, ITypeIdentifiable, IConvertibleToString, IMemberwiseCloneable
{
// The compiler also implicitly makes all classes implement the interfaces with the following code (unless otherwise specified)
#region IEquatable Members
public bool Equals(IEquatable other)
{
// let's suppose that this is equivalent to the current implementation of Object.Equals
return ClrInternals.Equals(this, other);
}
#endregion
#region IHashCodeGenerator Members
public int GetHashCode()
{
// let's suppose that this is equivalent to the current implementation of Object.GetHashCode
return ClrInternals.GetHashCode(this);
}
#endregion
#region ITypeIdentifiable Members
public Type GetType()
{
// let's suppose that this is equivalent to the current implementation of Object.GetType
return ClrInternals.GetType(this);
}
#endregion
#region IConvertibleToString Members
public string ToString()
{
// let's suppose that this is equivalent to the current implementation of Object.ToString
return this.GetType().ToString();
}
#endregion
// this one is perhaps a little goofy, since it doesn't satisfy any interface
// In order to be equivalent to the current Object.MemberwiseClone implementation, I've made this protected,
// but we cannot have a protected method that implements an interface, so this throws a wrench into things.
protected MyClassExampleA MemberwiseClone()
{
// let's suppose that this is equivalent ot the current implementation of Object.MemberwiseClone
return (MyClassExampleA)ClrInternals.MemberwiseClone(this);
}
// ** All of the above code is just a representation of the implicit semantics that the compiler/CLR applies to a class. Perhaps this code is not actually generated by the compiler for each class (that would be a lot of duplication!), but rather the CLR might handle this logic internally
}
// Ok, so now I'm implementing a general Stack class
public class Stack
{
// what type should I use for the parameter?
// I have five different interfaces to choose from that I know all classes implement, but which one should I pick?
public void Push(type??? item)
{
// ...
}
// what type should I use for the return type?
// I have five interfaces to choose from, but if I return one,
// then my caller can't utilize the methods defined in the other interfaces without casting.
// I know all classes implement all five interfaces, but is it possible that my Stack might also contain non-class objects that don't implement all interfaces? In that case it might be dangerous for the caller to cast the return value from one interface to another.
public type??? Pop()
{
// ...
}
// In C++ I could have used void* or defined the Stack class as a template
}
// moving on...
class StackUtilizer
{
// here I try to utilize the Stack class
public void UseStack(Stack stack)
{
// what type should I use for the variable to hold the result of the Stack.Pop method?
type??? item = stack.Pop();
// if I use IEquatable
IEquatable item1 = stack.Pop();
IEquatable item2 = stack.Pop();
item1.Equals(item2); // then I can do this
Type itemType = item1.GetType(); // but I can't do this
string s = item1.ToString(); // nor can I do this
// Ok, this calls for another interface that composes all of these other interfaces into one
}
}
// let's define a single interface that pulls all of these other interfaces together
public interface IObject : IEquatable, IHashCodeGenerator, ITypeIdentifiable, IConvertibleToString, IMemberwiseCloneable
{
// no need to define any methods on this interface. The purpose of this interface is merely to consolidate all of these other basic interfaces together.
}
// now we change the compiler rule to say that all classes implicitly implement the IObject interface
class MyClassExampleB : IObject
{
// ... <refer to MyClassExampleA for the implicit implementation of the interfaces>
}
// now let's try implementing that Stack class again
public class Stack
{
// I know that all classes implement the IObject interface, so it is an acceptable type to use as a parameter
public void Push(IObject item)
{
// ...
}
// again, since all classes implement IObject, I can use it as the return type
public IObject Pop()
{
// ...
throw new NotImplementedException("This is an example. The implementation of this method is irrelevant.");
}
}
class StackUtilizer
{
// here I try to utilize the Stack class
public void UseStack(Stack stack)
{
// now I can just use IObject for my variables holding the return value of the Stack.Pop method
IObject item = stack.Pop();
// if I use IObject
IObject item1 = stack.Pop();
IObject item2 = stack.Pop();
item1.Equals(item2); // then I can do this
Type itemType = item1.GetType(); // and I can do this
string s = item1.ToString(); // and I can do this
}
}
So, in the end we still have an IObject interface, similar to the current System.Object class. The open question is how the compiler/CLR would handle enforcing our rule that all classes implement the IObject interface.
I can think of three possible approaches:
- The compiler generates the implicit interface implementation for each class, which would cause a lot of duplication.
- The CLR would handle those interface implementations in a special way that would not require the compiler to actually generate code for each class.
- We define a base class, let's call it
Object (starting to sound familiar?), that implements the IObject interface and we change the rule to say that all classes implicitly inherit from Object (this is exactly what we have today but without the interfaces).