为什么C＃不支持受保护和内部可访问性的交集？ [英] Why C# does not support the intersection of Protected and Internal accessibility?

问题描述

受保护的内部：

受保护的和的联盟内部（比单独受保护或内部的限制少）

CLR 具有交叉点 的概念受保护的和内部可访问性，但C＃不支持此功能。

所以我的问题是：

省略此 Access修饰符是什么意思，请问有具体的原因吗？那么，为什么C＃不应该支持它呢？

解决方案

更新：C＃7.2在访问修饰符私有受保护的，这在某些方面似乎是错误的，但确实避免了我在下面描述的许多混乱的可能性，所以也许是一堆糟糕的事情中最好的。

我个人已经想要了好几次。有时，在程序集中公开一个类，并将一个或多个从其派生为 public 的类，有时，某些基类的成员仅由这些派生类，不应暴露给其他程序集中的受保护类（通常是构造函数，以防止其他程序集具有从其派生的类）。

尽可能严格地限制您的访问当然总是好事，因此，保护​​和内部的交集正是这里想要的。

相反，我必须声明成员内部 来模糊它。如果我使用允许我使用该交集的语言，那么我的代码中现在存在潜在的错误。

但是，考虑一下不利之处

就这样，受保护的内部给出<$ c $的并集的方式有些困惑c>受保护的和内部。通过这样的网站上的问题来判断，这可能是最容易被误解的访问权限。

我们应该怎么称呼它？ 内部受保护的？您能想象人们会多久将其与受保护的内部混淆吗？我们希望可以更清楚地区分某些东西，并且希望对内部保护使用相同的东西（因为我们仍然增加了混淆的可能性）。这不是一个不可能解决的问题，但是降低关键字数量也是一个好主意。

即使找到了命名问题的最佳答案，潜在的通过引入另一种访问权限级别的混乱并没有完全被克服。

因此，考虑到这一点，让我们再次看一下上行空间。我们不再需要使用内部来浪费我们需要的时间，从而减少了不当使用此类成员而导致的错误。好吧，这种情况多久出现一次，这些错误实际发生的可能性有多大？

因此，总的来说，虽然我确实偶尔希望C＃拥有此功能，但片刻的停顿通常让我很高兴他们没有

protected internal:

The union of protected and internal accessibility (this is less restrictive than protected or internal alone)

The CLR has the concept of intersection of protected and internal accessibility, but C# does not support this.

So my question is:

What's the meaning of omitting this Access Modifier, is there a concrete reason? So why C# should not support it?

解决方案

Update: C#7.2 is introducing this with the access modifier private protected, which seems wrong in a few ways but does avoid much of the potential for confusion I describe below, so is perhaps the best of a bad bunch.

Personally, I've wanted this quite a few times. There are times when one exposes a class and one or more classes derived from it as public in an assembly, and there are times when some member of the base class is only used by those derived classes and should not be exposed to protected classes in other assemblies (quite often the constructor, so as to prevent other assemblies from having classes that derive from it at all).

It is of course always good to define your access as restrictively as possible, and so the intersection of protected and internal is precisely what is wanted here.

Instead, I've had to kludge it by declaring the member internal. There is now a potential for bugs in my code that wouldn't have been there if I used a language that allowed me to use that intersection.

However, consider the downside.

As it is, there's some confusion about the way that protected internal gives the union of protected and internal. It's probably the most misunderstood access, judged by questions on sites like this.

What should we call it? internal protected? Can you imagine how often people would get that confused with protected internal? We'd want something more clearly differentiated, and we'd want the same for internal protected (because we've still increased its potential for confusion). It's not an impossible problem to answer, but keeping the number of keywords down is a good idea too.

Even if a perfect answer is found to the naming question, the potential for confusion by introducing yet another level of access is not entirely defeated.

So with that in mind, let's look at the upside again. We no longer have to kludge the times we need it by using internal, reducing bugs caused by inappropriately using such a member. Okay, how often does that come up, and how likely would such bugs actually be? Not very often really, and not very likely.

On balance therefore, while I do find myself occassionally wishing C# had this, a moment's pause normally makes me glad they did not.

这篇关于为什么C＃不支持受保护和内部可访问性的交集？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！