This is Sparta, or is it?
C#InheritanceTypesNamespacesC# Problem Overview
The following is an interview question. I came up with a solution, but I'm not sure why it works.
Question:
Without modifying the Sparta
class, write some code that makes MakeItReturnFalse
return false
.
public class Sparta : Place
{
public bool MakeItReturnFalse()
{
return this is Sparta;
}
}
My solution: (SPOILER)
>!public class Place
>!{
>!
public interface Sparta { }
>!}
But why does Sparta
in MakeItReturnFalse()
refer to {namespace}.Place.Sparta
instead of {namespace}.Sparta
?
C# Solutions
Solution 1 - C#
> But why does Sparta
in MakeItReturnFalse()
refer to {namespace}.Place.Sparta
instead of {namespace}.Sparta
?
Basically, because that's what the name lookup rules say. In the C# 5 specification, the relevant naming rules are in section 3.8 ("Namespace and type names").
The first couple of bullets - truncated and annotated - read:
> - If the namespace-or-type-name is of the form I
or of the form I<A1, ..., AK>
[so K = 0 in our case]:
> - If K is zero and the namespace-or-type-name appears within a generic method declaration [nope, no generic methods]
> - Otherwise, if the namespace-or-type-name appears within a type declaration, then for each instance type T (§10.3.1), starting with the instance type of that type declaration and continuing with the instance type of each enclosing class or struct declaration (if any):
> - If K
is zero and the declaration of T
includes a type parameter with name I
, then the namespace-or-type-name refers to that type parameter. [Nope]
> - Otherwise, if the namespace-or-type-name appears within the body of the type declaration, and T
or any of its base types contain a nested accessible type having name I
and K
type parameters, then the namespace-or-type-name refers to that type constructed with the given type arguments. [Bingo!]
> - If the previous steps were unsuccessful then, for each namespace N
, starting with the namespace in which the namespace-or-type-name occurs, continuing with each enclosing namespace (if any), and ending with the global namespace, the following steps are evaluated until an entity is located:
> - If K
is zero and I
is the name of a namespace in N
, then... [Yes, that would succeed]
So that final bullet point is what picks up the Sparta
class if the first bullet doesn't find anything... but when the base class Place
defines an interface Sparta
, it gets found before we consider the Sparta
class.
Note that if you make the nested type Place.Sparta
a class rather than an interface, it still compiles and returns false
- but the compiler issues a warning because it knows that an instance of Sparta
will never be an instance of the class Place.Sparta
. Likewise if you keep Place.Sparta
an interface but make the Sparta
class sealed
, you'll get a warning because no Sparta
instance could ever implement the interface.
Solution 2 - C#
When resolving a name to its value the "closeness" of the definition is used to resolve ambiguities. Whatever definition is "closest" is the one that is chosen.
The interface Sparta
is defined within a base class. The class Sparta
is defined in the containing namespace. Things defined within a base class are "closer" than things defined in the same namespace.
Solution 3 - C#
Beautiful question! I'd like to add a slightly longer explanation for those who don't do C# on a daily basis... because the question is a good reminder of name resolution issues in general.
Take the original code, slightly modified in the following ways:
- Let's print out the type names instead of comparing them as in the original expression (i.e.
return this is Sparta
). - Let's define the interface
Athena
in thePlace
superclass to illustrate interface name resolution. - Let's also print out the type name of
this
as it is bound in theSparta
class, just to make everything very clear.
The code looks like this:
public class Place {
public interface Athena { }
}
public class Sparta : Place
{
public void printTypeOfThis()
{
Console.WriteLine (this.GetType().Name);
}
public void printTypeOfSparta()
{
Console.WriteLine (typeof(Sparta));
}
public void printTypeOfAthena()
{
Console.WriteLine (typeof(Athena));
}
}
We now create a Sparta
object and call the three methods.
public static void Main(string[] args)
{
Sparta s = new Sparta();
s.printTypeOfThis();
s.printTypeOfSparta();
s.printTypeOfAthena();
}
}
The output we get is:
Sparta
Athena
Place+Athena
However, if we modify the Place class and define the interface Sparta:
public class Place {
public interface Athena { }
public interface Sparta { }
}
then it is this Sparta
-- the interface -- that will be available first to the name lookup mechanism and the output of our code will change to:
Sparta
Place+Sparta
Place+Athena
So we have effectively messed up with the type comparison in the MakeItReturnFalse
function definition just by defining the Sparta interface in the superclass, which is found first by the name resolution.
But why does C# chose to prioritize interfaces defined in the superclass in the name resolution? @JonSkeet knows! And if you read his answer you'll get the details of the name resolution protocol in C#.