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
EndDefine

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.