“受保护的内部”和派生的奇怪性 [英] Oddity with 'protected internal' and derivation
问题描述
我正在重构一些代码，将一些基类移动到单独的
程序集中。其中一个基类有一个成员属性，即
''protected internal''。但是，当我将这些基类移动到另一个
程序集时，编译器会抱怨派生类中的覆盖，
也被声明为受保护的内部，正在尝试更改访问权限
修改为受保护，显然并非如此。 （我已经检查了
程序集中的元数据，基类属性是''famorassem''。）
如果我将派生类声明更改为''protected ''，它运作正常。
任何人都有解释为什么它这样工作？
I am refactoring some code to move some base classes into a separate
assembly. One of these base classes has a member property which is
''protected internal''. However when I move these base classes to another
assembly, the compiler complains that the override in the derived class,
also declared as ''protected internal'', is trying to change the access
modified from ''protected'', which is clearly not the case. (I have checked
the metadata in the assembly and the base class property is ''famorassem''.)
If I change the derived class declaration to just ''protected'', it works OK.
Anybody have an explanation as to why it is working this way?
推荐答案
编译器消息不清楚，但我认为你得到一个错误
因为你有可见性冲突。
当你有protected internal时方法C1中的方法F在程序集A1中驻留
，F对任何地方的C1派生类都是可见的，加上
A1中的所有类。
现在，当您在程序集A2中放置派生类C2时，使用相同的受保护内部修饰符覆盖F
，覆盖仍然是派生的可见的
任何地方的课程 - 但它也是可见的
整个A2（但不是A1），而原始方法是可见的
整个A1（但不是A2）。 />
现在，如果A2中的某些非C2方法有一个C1对象并试图调用F，那么它应该是什么方法？它不能得到C1.F，因为A1的内部是
，它不能得到C2.F，因为它受C2保护。
A1中具有C2对象的非C1方法相同。
在我看来，除了
之外，不应使用受保护的内部内部课程。它要求将具有
受保护的内部方法的类暴露给其他程序集时遇到麻烦。
-
http://www.kynosarges.de
The compiler message is unclear but I think you''re getting an error
because you have a visibility conflict.
When you have "protected internal" method F in class C1 which resides
in assembly A1, F is visible to C1-derived classes anywhere, plus to
all classes in A1.
Now when you put a derived class C2 in assembly A2 that overrides F
with the same protected internal modifier, the override is still
visible to derived classes anywhere -- but it''s also visible
throughout A2 (but not A1) whereas the original method is visible
throughout A1 (but not A2).
Now if some non-C2 method in A2 has a C1 object and tries to call F,
just what method should it get? It can''t get C1.F because that''s
internal to A1, and it can''t get C2.F because that''s protected to C2.
Same for a non-C1 method in A1 that has a C2 object.
In my opinion, protected internal should not be used except with
internal classes. It''s asking for trouble to expose a class with
protected internal methods to other assemblies.
--
http://www.kynosarges.de
Chris Nahr < di ****** @ kynosarges.dewrote in message
news：hb ************************ ******** @ 4ax.com ...
"Chris Nahr" <di******@kynosarges.dewrote in message
news:hb********************************@4ax.com...
并且它无法获得C2.F，因为它受C2保护。
and it can''t get C2.F because that''s protected to C2.
这就是编译器正在做的事情，问题是它为什么这样做。
如果框架允许覆盖也是''内部保护''
然后它*可以*获得C2.F.问题是，框架是什么邪恶
通过坚持在派生的
类中更改对''protected''的访问来防止。我无法理解。
Well that''s what the compiler is doing, the question is why it is doing it.
If the framework allowed for the override to be also ''protected internal''
then it *could* get C2.F. The question is, what evil is the framework
preventing by insisting on changing the access to ''protected'' in the derived
class. This I cannot understand.
A1中具有C2对象的非C1方法相同。
Same for a non-C1 method in A1 that has a C2 object.
这意味着程序集的循环引用。
Which would mean a circular reference of assemblies.
在我看来，受保护的内部不应该是除了使用
内部课程时使用。要求将具有
保护内部方法的类暴露给其他程序集是一件麻烦事。
In my opinion, protected internal should not be used except with
internal classes. It''s asking for trouble to expose a class with
protected internal methods to other assemblies.
同意 - 我自己没有这样设计，我正在重构
别人的代码。这只是一个真正的PITA编译器以这种方式运行，因为这意味着我还必须重构从这个基类派生的几十个
类。将基类
移动到另一个程序集中的结果。
Agreed - I wouldn''t have designed it that way myself, I''m refactoring
someone else''s code. It''s just a real PITA that the compiler is behaving
this way because it means that I also have to refactor the several dozen
classes derived from this base class as a result of moving the base class
into a different assembly.
你好，
嗯，这就是编译器正在做的事情，问题是为什么这样做是为了b
。如果框架允许覆盖也是
''protected internal''那么它*可以*得到C2.F.问题是，什么
邪恶是通过坚持在派生类中更改访问权限来阻止
到''protected''的框架。这个我无法理解。
Well that''s what the compiler is doing, the question is why it is
doing it. If the framework allowed for the override to be also
''protected internal'' then it *could* get C2.F. The question is, what
evil is the framework preventing by insisting on changing the access
to ''protected'' in the derived class. This I cannot understand.
它会阻止你扩大？能见度。过去，这种方法对于A1组件中的任何类型都是可见的。如果你把它覆盖为一个受保护的
internala ??，那么你也会让它对A2组件可见，这是不一致的。
a ?? protected internala？ （在.NET中，[可见]系列或汇编）实际上是
a ?? protected或internala ??。你不能覆盖?? internala ??成员在另一个
汇编，但你可以覆盖一个?? protecteda ??当你覆盖一个受保护的
internala ??会员，它的内部??存在的一部分是留在了
的基础类中的A1 assemblya ??，只是一个?? ?? protecteda ??部分留给
你要覆盖。
It prevents you from a??broadeninga?? the visibility. That method used to be
visible to any types in the A1 assembly. If you override it as a??protected
internala??, you''ll make it visible to the A2 assembly too, which is not consistent.
a??protected internala?? (a??[visible to] family or assemblya?? in .NET) is actually
a??protected or internala??. You cannot override a??internala?? members in another
assembly, but you can override a??protecteda??. When you override a a??protected
internala?? member, its a??internala?? part of the existence is a??left behind in
the base class in the A1 assemblya??, just the a??protecteda?? part is left for
you to override.
这意味着程序集的循环引用。
Which would mean a circular reference of assemblies.
哪个适合.NET，为什么不呢？
Which is just OK with .NET, why not?
同意 - 我不会我自己就是这样设计的，我正在重构某人
Agreed - I wouldn''t have designed it that way myself, I''m refactoring someone
else'的代码。它只是一个真正的PITA，编译器就是这样表现的。
因为这意味着我还必须从这个基类重构几十个派生的
类。将基类移动到另一个
程序集的结果。
重构工具本可以为你处理，但当然我不能
确定，因为我不知道你的班级等级。
（H）Serge
else''s code. It''s just a real PITA that the compiler is behaving this way
because it means that I also have to refactor the several dozen classes derived
from this base class as a result of moving the base class into a different
assembly.
A refactoring tool could have handled that for you, but of course I cannot
be sure as I don''t know your class hierarchy.
(H) Serge
这篇关于“受保护的内部”和派生的奇怪性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
