Maybe it's academic, but responsibility for changing or exposing a property should be in the owner object and not in the calling object. Set Set and Get on object1 side are more in fitting with theory than Assign and Access on object 2 side....

Then again, the argument could also be made that you can bend the rules within a single tier and physical layer (DLL,EXE) :-)

I'm having one of those "OOP vs. reality" intellectual crises :)


>I guess what I meant was that ACCESS is the Get construct and ASSIGN is the Set construct. I don't really see the difference between using ASSIGN and creating your own Set method.
>
>>Well....but in theory object 1 shouldn't even *query* object 2's property directly at all, although it could call an object2.GetProperty("propertyname")...so...essentially...Access and Assign are N/A in a true object environment because you should be using Set and Get style constructs to message between objects....see?