为什么私有字段私有的类型,而不是该实例? [英] Why are private fields private to the type, not the instance?

查看:102
本文介绍了为什么私有字段私有的类型,而不是该实例?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在C#(和许多其他语言)是完全合法访问相同类型的其他实例的私人领域。例如:

In C# (and many other languages) it's perfectly legitimate to access private fields of other instances of the same type. For example:

public class Foo
{
    private bool aBool;

    public void DoBar(Foo anotherFoo)
    {
        if(anotherFoo.aBool) ...
    }
}

由于 C#规格(第3.5.1,3.5.2)美国访问私有字段是一个类型,而不是一个实例。我一直在与同事讨论这一点,我们正在努力想出一个原因,它的工作原理是这样的(而不是限制访问相同的实例)。

As the C# specification (sections 3.5.1, 3.5.2) states access to private fields is on a type, not an instance. I've been discussing this with a colleague and we're trying to come up with a reason why it works like this (rather than restricting access to the same instance).

我们可以拿出最好的反驳是平等的检查,其中类可能需要访问私有字段,以确定与另一个实例相等。是否还有其他原因?或者一些金色的原因,绝对意味着它必须像这样工作或某事是完全不可能的?

The best argument we could come up with is for equality checks where the class may want to access private fields to determine equality with another instance. Are there any other reasons? Or some golden reason that absolutely means it must work like this or something would be completely impossible?

推荐答案

我想其中一个原因是这样工作是因为访问修饰符在工作中的编译时间的。因此,确定一个给定的对象是否也是<青霉>电流的目的是不容易做到的。例如,考虑这个code:

I think one reason it works this way is because access modifiers work at compile time. As such, determining whether or not a given object is also the current object isn't easy to do. For example, consider this code:

public class Foo
{
    private int bar;

    public void Baz(Foo other)
    {
        other.bar = 2;
    }

    public void Boo()
    {
        Baz(this);
    }
}

编译器都未必能够弄清楚,实际上这个?不是在所有情况。有人可能会说,这只是不应该再编译,但是这意味着我们有一个code路径,其中私人实例成员的正确的实例的是无法访问的,我认为这是更差

Can the compiler necessarily figure out that other is actually this? Not in all cases. One could argue that this just shouldn't compile then, but that means we have a code path where a private instance member of the correct instance isn't accessible, which I think is even worse.

只需要类型层次,而不是对象级别的可视性,确保问题是容易处理,以及使这似乎是它的的工作的真正的工作情况。

Only requiring type-level rather than object-level visibility ensures that the problem is tractable, as well as making a situation that seems like it should work actually work.

修改:Danilel Hilgarth的观点,这种推理是向后确实有可取之处。语言的设计者可以创建他们想要的语言和编译器编写者必须符合它。话虽这么说,语言的设计者确实有一定的激励,使其更容易为编译器的编写者做好自己的工作。 (虽然在这种情况下,它是很容易认为,私有成员然后可以的只有的可通过这个(隐或​​显式)访问)。

EDIT: Danilel Hilgarth's point that this reasoning is backwards does have merit. Language designers can create the language they want, and compiler writers must conform to it. That being said, language designers do have some incentive to make it easier for compiler writers to do their job. (Though in this case, it's easy enough to argue that private members could then only be accessed via this (either implicitly or explicitly)).

不过,我相信,使问题更加混乱比它需要。大多数用户(包括我自己)会觉得不必要地限制如果上述code没有工作:毕竟,这是的我的的数据,我试图访问!我为什么要要经过这个

However, I believe that makes the issue more confusing than it needs to be. Most users (myself included) would find it unneccessarily limiting if the above code didn't work: after all, that's my data I'm trying to access! Why should I have to go through this?

在总之,我觉得我可能夸大了它是困难编译器的情况。我真正的意思跨越明白的是,上述情况似乎像一个设计师想拥有的工作。

In short, I think I may have overstated the case for it being "difficult" for the compiler. What I really meant to get across is that above situation seems like one that the designers would like to have work.

这篇关于为什么私有字段私有的类型,而不是该实例?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆