Why are private fields private to the type, not th

Question

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) ...
    }
}

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?

Answer 1

The reason indeed is equality check, comparison, cloning, operator overloading... It would be very tricky to implement operator+ on complex numbers, for example.

Answer 2

Great answers given above. I would add that part of this problem is the fact that instantiating a class inside itself is even allowed in the first place. It makes since in a recursive logic "for" loop, for example, to use that type of trick as long as you have logic to end the recursion. But instantiating or passing the same class inside itself without creating such loops logically creates its own dangers, even though its a widely accepted programming paradigm. For example, a C# Class can instantiate a copy of itself in its default constructor, but that doesn't break any rules or create causal loops. Why?

BTW....this same problem applies to "protected" members as well. :(

I never accepted that programming paradigm fully because it still comes with a whole suite of issues and risks that most programmers don't fully grasp until issues like this problem rise up and confuse people and defy the whole reason for having private members.

This "weird and wacky" aspect of C# is yet one more reason why good programming has nothing to do with experience and skill, but just knowing the tricks and traps.....like working on a car. Its the argument that rules were meant to be broken, which is a very bad model for any computing language.

Answer 3

It seems to me that if data was private to other instances of the same type, it wouldn't necessarily be the same type anymore. It wouldn't seem to behave or act the same as other instances. Behavior could easily be modified based on that private internal data. That would just spread confusion in my opinion.

Loosely speaking, I personally think that writing classes derived from a base class offers similar functionality you are describing with 'having private data per instance'. Instead, you just have a new class definition per 'unique' type.

Answer 4

This is perfectly legitimate in many languages (C++ for one). The access modifiers come from the encapsulation principle in OOP. The idea is to restrict access to outside, in this case outside is other classes. Any nested class in C# for example can access it's parents private members also.

While this is a design choice for a language designer. The restriction of this access can complicate some very common scenarios extremely without contributing much to isolation of entities.

There is a similar discussion here