The foxNET series: protected is protected, or is it?

As a Visual FoxPro developer you discover many familiarities when you read (or write) .NET code. After all, you have been working in an object oriented environment for over a decade whereas the poor VB guys had to jump right from infancy into adulthood, right?
Is it that easy? No. In Visual FoxPro the scope of these modifiers is the object. The following program produces an error in Visual FoxPro:

ox = CreateObject("Sample")
? ox.SetValue(ox,"ox")
oy = CreateObject("Sample")
? oy.SetValue(ox,"oy")

Define Class Sample as Custom
Protected cValue
Procedure SetValue( toRef, tcValue )
toRef.cValue = m.tcValue
Return m.tcValue

The first method call works just fine. You can call a method of ox and then use a reference to ox to change the property. If you pass a different instance of the same class, you cannot access the protected properties of the second object. This behaviour is one reason that protected properties are not that widely used among Visual FoxPro developers (compared to other languages, at least). If you have a class where two instances need to exchange data, you have to use a public interface that is open to everyone else, too. Now look at the same program written in C

class Program
static void Main(string[] args)
Sample ox = new Sample();
Console.WriteLine(ox.SetValue(ox, "ox"));
Sample oy = new Sample();
Console.WriteLine(oy.SetValue(ox, "oy"));
class Sample
protected string cValue;
public string SetValue(Sample toRef, string tcValue)
toRef.cValue = tcValue;
return tcValue;

This code compiles and runs just fine. In Visual FoxPro the visibility of members is scoped to the object instance. In .NET it is scoped to the class (actually, the type). Any instance of a class has access to every single private member of every other instance of the same class. This makes non-public members much more useful than in Visual FoxPro.