>>But consider:
>>
>>A. object2.SetMyProp(myvalue)
>>
>>B. object2.myprop = myvalue
>>
>>If in B myvalue is intercepted by object2.myprop's ASSIGN event and then assigned, is that similar to A?
>
>Hi John and Gary,
>
>I'm with Gary on this one the syntax is different, but the object that owns the property is still controlling it completely. It may not be quite as readable, but if you always use Access and Assign to get and set properties of another object, it's pretty clear what's going on.

Josh,

Except for the fact that the outside world has to know the name of MyProp. For example, I design a class and it has a property named nTotal. The property is used by the outside world to say Obj.nTotal = obj.nTotal + SomeValue, which is trapped by an assign method and processed correctly. Now I design another object and give it a method named AddToTotal and it is used in

Obj.AddToTotal(SomeValue)

which interface is cleaner? The answer lies in part in how well the implmentation fo teh totalling is hidden from the outside world. In the former the outside world does the totalling by adding a value to the current property value. In the latter, the object with the nTotal property does the totalling and no outside object even knows what the name of the property is. Also, if I later choose to modify the way the class does its totalling I can do that easily in the latter case without changing anything but the AddToTotal method, in the former case I would need to be careful not to change the name of the property or else I would need to visit every object that might use that property and make changes there as well.

It is an issue of external coupling. Using methods reduces external coupling. Does this mean we should never use properties as public interface components? No, it simply means that we need to be aware that using properties as part of the public interface increases the external couling and produces issues that need to be addressed because of that. Then choose the most pratical approach to solving the problem.