blocks|key|2642268|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2642269|但是为什么MakeItReturnFalse()中的Sparta指的是{namespace}.Place.Sparta而不是{namespace}.Sparta？|blockquote|offset|length|style|CODE|2642270|2642271|2642272|基本上，因为这就是名称查找规则所说的。在C#+5规范中，相关的命名规则在3.8节(“命名空间和类型名”)中。|2642273|前几个项目符号-截断和注释-阅读：|2642274|2642275|2642276|2642277|如果命名空间或类型名称的形式为I或I<A1,+...,+AK>+so+K=0，在我们的情况下为：|BOLD|2642278|如果K为零并且命名空间或类型名称出现在泛型方法声明内，则没有泛型如果命名空间或类型名称出现在类型声明内，则对于每个实例类型T+(§10.3.1)，从该类型声明的实例类型开始，接着是每个封闭类或结构声明的实例类型(如果有)：|unordered-list-item|2642279|如果K为零，并且T的声明包含名为I的类型参数，则命名空间或类型名称将引用该类型参数。Nope|2642280|Otherwise，如果命名空间或类型名称出现在类型声明的主体中，并且T+或其任何基类型包含具有名称I和K类型参数的嵌套可访问类型，则命名空间或类型名称引用使用给定类型参数构造的类型。Bingo!|2642281|2642282|2642283|​|2642284|2642285|2642286|如果前面的步骤不成功，则对于每个命名空间N，从出现命名空间或类型名的命名空间开始，继续每个封闭命名空间(如果有)，并以全局命名空间结束，将评估以下步骤，直到找到实体为止：|2642287|如果K为零，并且I是N中命名空间的名称，则...[是的，将会对进行|2642288|2642289|2642290|2642291|因此，最后一个要点是，如果第一个项目符号没有找到任何内容，那么将选择Sparta类……但是当基类Place定义了一个接口Sparta时，它在我们考虑Sparta类之前就被发现了。|2642292|请注意，如果将嵌套类型Place.Sparta设置为类而不是接口，它仍然会编译并返回false+-但编译器会发出警告，因为它知道Sparta的实例永远不会是Place.Sparta类的实例。同样，如果将Place.Sparta保留为接口，但将Sparta类设置为sealed，您将收到一条警告，因为没有任何Sparta实例可以实现该接口。|2642293|entityMap^0|0|5|J|Q|6|Z|O|1Q|I|0|0|0|0|0|0|0|0|F|1|H|E|W|F|0|W|27|1|0|1A|2|1|8|1|G|1|1|0|10|11|1P|Z|1|1E|1|1G|1|1|0|0|0|1|0|0|1|0|0|0|2D|K|1|1|0|X|2|1|8|1|A|1|1|0|0|0|1|0|0|2H|Y|6|1C|5|1O|6|22|6|0|0|4P|B|C|16|5|1S|6|26|C|2T|C|3D|6|3N|6|49|6|0^^$0|@$1|2|3|-4|4|5|6|1J|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|1K|7|@$D|1L|E|1M|F|G]|$D|1N|E|1O|F|G]|$D|1P|E|1Q|F|G]|$D|1R|E|1S|F|G]]|8|@]|9|$]]|$1|H|3|-4|4|5|6|1T|7|@]|8|@]|9|$]]|$1|I|3|-4|4|5|6|1U|7|@]|8|@]|9|$]]|$1|J|3|K|4|5|6|1V|7|@]|8|@]|9|$]]|$1|L|3|M|4|5|6|1W|7|@]|8|@]|9|$]]|$1|N|3|-4|4|5|6|1X|7|@]|8|@]|9|$]]|$1|O|3|-4|4|C|6|1Y|7|@]|8|@]|9|$]]|$1|P|3|-4|4|5|6|1Z|7|@]|8|@]|9|$]]|$1|Q|3|R|4|5|6|20|7|@$D|21|E|22|F|G]|$D|23|E|24|F|G]|$D|25|E|26|F|S]]|8|@]|9|$]]|$1|T|3|U|4|V|6|27|7|@$D|28|E|29|F|S]]|8|@]|9|$]]|$1|W|3|X|4|V|6|2A|7|@$D|2B|E|2C|F|S]|$D|2D|E|2E|F|G]|$D|2F|E|2G|F|G]|$D|2H|E|2I|F|G]]|8|@]|9|$]]|$1|Y|3|Z|4|V|6|2J|7|@$D|2K|E|2L|F|S]|$D|2M|E|2N|F|S]|$D|2O|E|2P|F|G]|$D|2Q|E|2R|F|G]|$D|2S|E|2T|F|G]]|8|@]|9|$]]|$1|10|3|-4|4|5|6|2U|7|@]|8|@]|9|$]]|$1|11|3|-4|4|5|6|2V|7|@]|8|@]|9|$]]|$1|12|3|13|4|5|6|2W|7|@$D|2X|E|2Y|F|S]]|8|@]|9|$]]|$1|14|3|13|4|5|6|2Z|7|@$D|30|E|31|F|S]]|8|@]|9|$]]|$1|15|3|-4|4|5|6|32|7|@]|8|@]|9|$]]|$1|16|3|17|4|V|6|33|7|@$D|34|E|35|F|S]|$D|36|E|37|F|G]]|8|@]|9|$]]|$1|18|3|19|4|V|6|38|7|@$D|39|E|3A|F|S]|$D|3B|E|3C|F|G]|$D|3D|E|3E|F|G]|$D|3F|E|3G|F|G]]|8|@]|9|$]]|$1|1A|3|-4|4|5|6|3H|7|@]|8|@]|9|$]]|$1|1B|3|-4|4|5|6|3I|7|@]|8|@]|9|$]]|$1|1C|3|13|4|5|6|3J|7|@$D|3K|E|3L|F|S]]|8|@]|9|$]]|$1|1D|3|1E|4|5|6|3M|7|@$D|3N|E|3O|F|S]|$D|3P|E|3Q|F|G]|$D|3R|E|3S|F|G]|$D|3T|E|3U|F|G]|$D|3V|E|3W|F|G]]|8|@]|9|$]]|$1|1F|3|1G|4|5|6|3X|7|@$D|3Y|E|3Z|F|S]|$D|40|E|41|F|G]|$D|42|E|43|F|G]|$D|44|E|45|F|G]|$D|46|E|47|F|G]|$D|48|E|49|F|G]|$D|4A|E|4B|F|G]|$D|4C|E|4D|F|G]|$D|4E|E|4F|F|G]]|8|@]|9|$]]|$1|1H|3|-4|4|5|6|4G|7|@]|8|@]|9|$]]]|1I|$]]

<blockquote>
 But why does <code>Sparta</code> in <code>MakeItReturnFalse()</code> refer to <code>{namespace}.Place.Sparta</code> instead of <code>{namespace}.Sparta</code>?
</blockquote>

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:

<blockquote>
 <ul>
 <li>If the namespace-or-type-name is of the form <code>I</code> or of the form <code>I&lt;A1, ..., AK&gt;</code> [so K = 0 in our case]:
 
 <ul>
 <li>If K is zero and the namespace-or-type-name appears within a generic method declaration [nope, no generic methods]</li>
 <li>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):
 
 <ul>
 <li>If <code>K</code> is zero and the declaration of <code>T</code> includes a type parameter with name <code>I</code>, then the namespace-or-type-name refers to that type parameter. [Nope]</li>
 <li>Otherwise, if the namespace-or-type-name appears within the body of the type declaration, and <code>T</code> or any of its base types contain a nested accessible type having name <code>I</code> and <code>K</code> type parameters, then the namespace-or-type-name refers to that type constructed with the given type arguments. [Bingo!]</li>
 </ul></li>
 </ul></li>
 <li>If the previous steps were unsuccessful then, for each namespace <code>N</code>, 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:
 
 <ul>
 <li>If <code>K</code> is zero and <code>I</code> is the name of a namespace in <code>N</code>, then... [Yes, that would succeed]</li>
 </ul></li>
 </ul>
</blockquote>

So that final bullet point is what picks up the <code>Sparta</code> class if the first bullet doesn't find anything... but when the base class <code>Place</code> defines an interface <code>Sparta</code>, it gets found before we consider the <code>Sparta</code> class.

Note that if you make the nested type <code>Place.Sparta</code> a class rather than an interface, it still compiles and returns <code>false</code> - but the compiler issues a warning because it knows that an instance of <code>Sparta</code> will never be an instance of the class <code>Place.Sparta</code>. Likewise if you keep <code>Place.Sparta</code> an interface but make the <code>Sparta</code> class <code>sealed</code>, you'll get a warning because no <code>Sparta</code> instance could ever implement the interface.

blocks|key|106057|text|当将一个名称解析为它的值时，定义的“贴近性”被用来解决歧义。无论什么定义是“最接近的”，都是所选择的定义。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|106058|接口Sparta是在基类中定义的。类Sparta在包含的命名空间中定义。在基类中定义的内容比在同一名称空间中定义的内容“更接近”。|offset|length|style|CODE|106059|entityMap^0|0|2|6|I|6|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]|$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|P|8|@]|9|@]|A|$]]]|I|$]]

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 <code>Sparta</code> is defined within a base class. The class <code>Sparta</code> is defined in the containing namespace. Things defined within a base class are "closer" than things defined in the same namespace.

blocks|key|2854001|text|问得好！我想为那些每天不做C#的人补充一点更长的解释……因为这个问题很好地提醒了一般的名称解析问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2854002|以原始代码为例，通过以下方式略微修改：|2854003|2854004|让我们打印出类型名称，而不是像在原始表达式中那样比较它们(例如，在Place超类中定义接口Athena以说明接口名称解析。|unordered-list-item|offset|length|style|CODE|2854005|让我们还打印出this的类型名称，因为它绑定在Sparta类中，只是为了让一切变得非常清楚。|2854006|2854007|代码如下所示：|2854008|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));
++++}
}|code-block|syntax|javascript|2854009|现在我们创建一个Sparta对象并调用这三个方法。|2854010|public+static+void+Main(string[]+args)
++++{
++++++++Sparta+s+=+new+Sparta();
++++++++s.printTypeOfThis();
++++++++s.printTypeOfSparta();
++++++++s.printTypeOfAthena();
++++}
}|2854011|我们得到的输出是：|2854012|Sparta
Athena
Place%2BAthena|2854013|但是，如果我们修改Place类并定义接口Sparta：|2854014|+++public+class+Place+{
++++++++public+interface+Athena+{+}
++++++++public+interface+Sparta+{+}+
++++}|2854015|然后这个Sparta+-接口-将首先可用于名称查找机制，我们代码的输出将更改为：|2854016|Sparta
Place%2BSparta
Place%2BAthena|2854017|因此，我们通过在超类中定义Sparta接口，有效地处理了MakeItReturnFalse函数定义中的类型比较，超类首先通过名称解析找到超类。|2854018|但为什么C#选择在名称解析中优先考虑超类中定义的接口？@JonSkeet知道！如果您阅读了他的答案，您将获得C#中名称解析协议的详细信息。|2854019|entityMap^0|0|0|0|X|5|19|6|0|7|4|N|6|0|0|0|0|8|6|0|0|0|0|0|0|4|6|0|0|S|H|0|0^^$0|@$1|2|3|4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1I|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|1K|8|@$H|1L|I|1M|J|K]|$H|1N|I|1O|J|K]]|9|@]|A|$]]|$1|L|3|M|5|G|7|1P|8|@$H|1Q|I|1R|J|K]|$H|1S|I|1T|J|K]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1V|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1W|8|@]|9|@]|A|$T|U]]|$1|V|3|W|5|6|7|1X|8|@$H|1Y|I|1Z|J|K]]|9|@]|A|$]]|$1|X|3|Y|5|S|7|20|8|@]|9|@]|A|$T|U]]|$1|Z|3|10|5|6|7|21|8|@]|9|@]|A|$]]|$1|11|3|12|5|S|7|22|8|@]|9|@]|A|$T|U]]|$1|13|3|14|5|6|7|23|8|@]|9|@]|A|$]]|$1|15|3|16|5|S|7|24|8|@]|9|@]|A|$T|U]]|$1|17|3|18|5|6|7|25|8|@$H|26|I|27|J|K]]|9|@]|A|$]]|$1|19|3|1A|5|S|7|28|8|@]|9|@]|A|$T|U]]|$1|1B|3|1C|5|6|7|29|8|@$H|2A|I|2B|J|K]]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|2C|8|@]|9|@]|A|$]]|$1|1F|3|-4|5|6|7|2D|8|@]|9|@]|A|$]]]|1G|$]]

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: 

<ul>
<li>Let's print out the type names instead of comparing them as in the original expression (i.e. <code>return this is Sparta</code>).</li>
<li>Let's define the interface <code>Athena</code> in the <code>Place</code> superclass to illustrate interface name resolution. </li>
<li>Let's also print out the type name of <code>this</code> as it is bound in the <code>Sparta</code> class, just to make everything very clear.</li>
</ul>

The code looks like this: 

<pre><code>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));
 }
}
</code></pre>

We now create a <code>Sparta</code> object and call the three methods.

<pre><code>public static void Main(string[] args)
 {
 Sparta s = new Sparta();
 s.printTypeOfThis();
 s.printTypeOfSparta();
 s.printTypeOfAthena();
 }
}
</code></pre>

The output we get is: 

<pre><code>Sparta
Athena
Place+Athena
</code></pre>

However, if we modify the Place class and define the interface Sparta: 

<pre><code> public class Place {
 public interface Athena { }
 public interface Sparta { } 
 }
</code></pre>

then it is this <code>Sparta</code> -- the interface -- that will be available first to the name lookup mechanism and the output of our code will change to: 

<pre><code>Sparta
Place+Sparta
Place+Athena
</code></pre>

So we have effectively messed up with the type comparison in the <code>MakeItReturnFalse</code> 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#.

The following is an interview question. I came up with a solution, but I'm not sure why it works.

<hr>

Question:

Without modifying the <code>Sparta</code> class, write some code that makes <code>MakeItReturnFalse</code> return <code>false</code>.

<pre><code>public class Sparta : Place
{
 public bool MakeItReturnFalse()
 {
 return this is Sparta;
 }
}
</code></pre>

<hr>

My solution: (SPOILER)

<blockquote class="spoiler">
 <code>public class Place</code> 
<code>{</code> 
<code></code> <code></code> <code></code> <code>public interface Sparta { }</code> 
<code>}</code>
</blockquote>

But why does <code>Sparta</code> in <code>MakeItReturnFalse()</code> refer to <code>{namespace}.Place.Sparta</code> instead of <code>{namespace}.Sparta</code>?

This is Sparta, or is it?

编译器

以下是一个面试问题。我想出了一个解决方案，但我不确定它为什么有效。问题：在不修改Sparta类的情况下，编写一些代码使MakeItReturnFalse返回false。public class Sparta : Place{    public bool MakeItReturnFalse()    {        ...

问这是斯巴达，还是真的？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问这是斯巴达，还是真的？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问这是斯巴达，还是真的？
EN