>>>If you really want to do that, keep all your code in a class and subclass it. But whomever you are supposed to be working with won't have access to the methods in your class.
>>
>>The very problem with classes being not shared or even sharing it as readonly is that not every member of the development team could use it in setting default forms or in mapping fields. That said, it breaks the essence of OOP methodology.
>>
>
>Jess, you're incredibly wrong here. The key to sucessful class design is a consistent, well-documented interface. You can put all of a class into a class library and compile it, and make it available as long as the public methods and properties are documented. Inserting a subclass between the closed base class and the instantiation of controls and objects make it possible to enhance or decorate a class whose internal behavior is completely hidden, but whose results are well documented. Proper OOP should permit you to subclass an existing class without needing to know what goes on inside the class itself; if you really do implement OO designs, then you should be able to rip out a class at any ayer, replace it with a clas offering an identical interface, but with possibly radiclly different implementation details and behaviors, and your code should keep right on working.
>
>My objection to hidden code is not that the hidden code is bad, but if you instantiate objects directly from the closed class, you can't make enhancements or decorations to the class without having to hack the instantiation. It's the sme logic behind not working directly from VFP's base classes, but instead, from a subclass of it, so that changes to the base class n be made without altering the rest of your class hierarchy.

Yes, I agree with you 200%. It's just that I missed VFP's feature of compiling a class then hiding the methods by replacing with blank spaces then sharing the same without setting the physical file into readonly attributes.