>>The usual answer to this is that you can reorganize your stuff, and group your related functionality into a separate class. So if A is having dependent methods K and L which are not used anywhere else, it may be a good moment to think of a new class which will have new methods: A, K and L, and the A method in the orginal class will simply call the A method of an object based on this new class.
>
>I will give you "may be a good moment...", that leaves room for "may not." At times I think it would be better to keep everything in one place.

Sure, in the same .vcx :).

It's more a matter of style and habits. Pretty much like a naming convention. Anyway, in a case when I suspect I have an island of functionality which I may use elsewhere, I don't waste much time thinking - I make it a separate class. But then I've also found that good grouping of things into more of smaller classlibs made sense for me - keep related things together. On the last project I had an away team, and pretty soon discovered it's a major hassle to split the work the way the classes were laid out - forms in one classlib, datamanagers in another, business managers and utilities in other two. We rearranged the whole thing so that only datamanagers stayed together; the rest was arranged by form - i.e. the form class, its businessmanager(s) and any specific utilities were in one classlib. It was far easier to shuffle classlibs back and forth.

This example does not really answer this issue, it only shows that there are many different ways you can keep your code organized. Too bad the enhancement you want would require a major rewrite of VFP class engine.