Not everything derives from object

re: Not everything derives from object

ruju — Wed, 04 Jul 2012 13:07:21 GMT

gr8!! this is what i was searching for. I had a gr8 confusion about interface type.

re: Not everything derives from object

甜番薯 — Sat, 30 Jan 2010 02:25:56 GMT

I translate this post to chinese:

http://www.cnblogs.com/tianfan/archive/2010/01/28/not-everything-derives-from-object.html

我已将此文章翻译成中文：

http://www.cnblogs.com/tianfan/archive/2010/01/28/not-everything-derives-from-object.html

re: Not everything derives from object

AM — Thu, 28 Jan 2010 15:50:05 GMT

The ability to call System.Object's members is a C# language implementation decision as opposed to the implementation of a language like VB.Net(@Patrick upcast to access System.Object members).

Calling ToString() on an instance of an object implementing an interface (Iface) produces IL as such:

L_000f: callvirt instance string [mscorlib]System.Object::ToString()

Specifying "string ToString();" on the Interface changes the IL such:

L_000f: callvirt instance string Iface::ToString()

So as the author states the interface isn't inheriting those members from System.Object, it's the compiler that decides to resolve those members to the System.Object class because its a resonable assumption to make that any type that implements Iface is convertable to an object.

re: Not everything derives from object

Bob Bedell — Thu, 21 Jan 2010 03:39:05 GMT

13.2 "The members of class object are not, strictly speaking, members of any iinterface."

How about this one?

interface MyInterface

{

bool Equals(object obj);

int GetHashCode();

Type GetType();

string ToString();

}

class MyClass : MyInterface

{

// MyInterface is implicitly implemented because MyClass implicitly derives from type object.

}

Isn't it really the case that the members of type object are implicitly members of EVERY interface?

re: Not everything derives from object

Rakesh — Mon, 14 Sep 2009 13:34:51 GMT

Any idea why following code does not generate compile time error?

public interface ITest
   {
       void PrintMessage();
   }
// Class does not implement ITest interface.
   public class BaseClass
   {
   }

class Program
   {
       static void Main(string[] args)
       {
           BaseClass bclass = new BaseClass();
           // Why compiler does not generate error here....
           ((ITest)bclass).PrintMessage();
       }
   }

First off, of course it generates an error at runtime. But why not at compile time?

Suppose we rewrite your program like this:

BaseClass bclass = GetSomething();
((ITest)bclass).PrintMessage();

Do you agree that the compiler cannot produce an error here? Since BaseClass is not sealed, there could be a derived class that implements ITest, and an instance of it could be returned by GetSomething.

The compiler is not smart enough to deduce that bclass is always of type BaseClass and never of a more derived class on the codepath that has the cast operator. We do flow analysis, but only for the purposes of determining reachability and definite assignment, not for analyzing the possible runtime types of variables. We could implement such a system, but it would be a lot of work for a small gain.

-- Eric

re: Not everything derives from object

STJ — Tue, 08 Sep 2009 21:54:24 GMT

What about the "null type"? (see C# Language Specification §9.4.4.6, §11.2.7)

We decided during the C# 3 design and specification process that having a special type that only contains one value, null, was a bad idea. It seems plausible, and other language specs also do it this way, but ultimately it adds very little value. The null type is quite unusual in that its the only type that doesn't have a CLR type object associated with it. It is conceptually easier to simply have some expressions be typeless, and be OK with that, than to invent an ad-hoc type solely for the purpose of being able to say what the type of the null literal expression is. This language should have been removed from the C# 3 spec. -- Eric

re: Not everything derives from object

antlypls — Mon, 07 Sep 2009 14:18:23 GMT

Also, this myth is sustained by Jeff Richter's book "CLR via C#, 2nd ed", there is section called "All types are derived from System.Object" in Chapter 4 "Type Fundamentals" of the book.

re: Not everything derives from object

Orhan — Fri, 28 Aug 2009 10:32:42 GMT

http://msdn.microsoft.com/tr-tr/library/ms173156(en-us).aspx this article says "An interface can itself inherit from multiple interfaces.". so, how about that?

re: Not everything derives from object

Vladimir Reshetnikov — Mon, 17 Aug 2009 22:57:22 GMT

Even the authors of C# Language Specification were deceived by this myth. :-)

Section 4.2.2 says: "The object class type is the ultimate base class of all other types . Every type in C# directly or indirectly derives from the object class type."

Yep. Mads is aware of the error and will correct the spec in the next version. -- Eric

Actually, there are some very special value types (like System.TypedReference) that are not convertible to object.

Yep. One of these days I'll do a blog post about those very special types. That will at the very least force me to figure out how they work. :-) -- Eric

re: Not everything derives from object

pminaev — Tue, 11 Aug 2009 01:33:26 GMT

@leo, it works because C# language spec requires it to; 7.3 "Member lookup":

"A member lookup of a name N with K type parameters in a type T is processed as follows:

* If T is a type parameter, then the set is the union of the sets of accessible members named N in each of the types specified as a primary constraint or secondary constraint (§10.1.5) for T, along with the set of accessible members named N in Object.

* Otherwise, the set consists of all accessible (§3.5) members named N in T, including inherited members and the accessible members named N in Object. If T is a constructed type, the set of members is obtained by substituting type arguments as described in §10.3.2. Members that include an override modifier are excluded from the set."

Note how it specifically calls for looking up members in Object, and at the same time makes a distinction between "inherited members" and "members in Object".

What is the rationale for this when T is an interface type is a different question, but it is understandable. After all, if you can call instance members of Object on a value of interface type as if they were "inherited" from Object, it would only be logical to extend the same pseudo-inheritance to static members.