Hi again Rox ---

>And I agree, _Access and _Access, *IF* used correctly, can be used to prevent direct manipulation. But my point was that using them correctly in regards to OOP theory is up to the developer. There is nothing in these constructs that would prevent us from using them to do the exact opposite. For example, I could have an _Assign on an Employee ID field that goes out and changes the properties of my Payroll Business Object and my User Security object once a new Employee ID is validated and accepted. Now if I don't setup similar _Assigns on those properties in my other objects, I'm still not circumventing direct manipulation.
>

You can put a trap into THIS_ACCESS to catch all unprotected properties in test phase or in production for those properties you don't want to bother with _access or _assigns. :-)


>All-in-all John I think you've shown us a valuable lesson with this thread.
As technology gives us more perks and cool stuff to aide development, we should always take time to reflect on established OOP/OOSE theories before rushing to use the new stuff just to 'be cool' if you will, and see how the new perk fits into the bigger picture before we find ourselves looking backwards on a completed project and paying homage to the gods of hindsight with a mantra such as "Well, I could of done that better..."
>

I appreciate the thanks :-)