Mike,

>During distribution/sharing of code with another programmer, the aggregating of various classes and modules is fine. The compiler does not need packages.

It's not the compiler that needs classlib packaging at all. The packagaing is solely for the developer to assemble classes into manageable entities.

>I did and she said precious little about it. She said a class is sort of a package and that a class can be the package.

And a class can be in more than one package. It's a function of what kind of package it is.

>The packaging just gets in the way. If it was virtual and not physical that would be ideal.

We just differ in opinion on this. For me the classlib is a convenient physical packaging of closely related classes. It's convenient when using them from the PM, it's convenient to distribute them.

>Sure it's convenient until, as you said, you need to share cgrid between two apps.

That's exactly why it is where it is. 99.9% of the apps use cControl.vcx.

>Why? It's no hardship on the computer and you already directly refer to the particular classes by name.

500 classes in 500 classlibs requires 1000 lines of treeview to display. 500 classes in 30 classlibs requires 530 lines of treeview. I guess you just love to scroll the PM window. *s*

>>Did he refactor it all the way down to one class per classlib?
>>
>
>Of course not. The refactoring impact on the existing installations prevented him.

Are you sure that's what drove Drew's decision? I won't be convinced of that until Drew posts a reply here.

>Let's find a way to keep the flexibility to categorize things without physically relocating them.

Since classlibs are tables it's quite easy to use other tables to provide whatever logical packaging you desire.

>The class is not a quark. It is by definition the atom in OOP.

I'm saying your 1 class/classlib is a subatomic approach the classlib packaging issue.