Hi Mike,

>>I think this is a matter of personal preferences. When all nodes of all classes are expanded you have a list that is twice as long as you have classes, while if you have only a few classlibs you can more effectively drill down to the class you need.

>I think you think too many things are personal preference. Imagine a class library with 100 classes. To access 1 of these in the PM, I must expand that classlib, so that I now have to look at 100 classes, move the mouse to one class and double click.

>If I have 100 classlibs and they are not expanded (and why should they be?), I have to scan 100 classlibs, move the mouse to one classlib, expand it, move the mouse a little more, double click.

>There is no significant difference. There is nothing gained by having them in one classlib. Should I choose to use one of these classes in a new project, I will only have 1 class, not 100.

Well, I think there is, in this circumstance anyways: I´d prefer to have all classlibs collapsed. In an average application I´ve got about 6 classlibs. If I´m looking, for example, for a crystal reports specific class, I´d expand the crystal reports classlib (which contains about 10 classes or so) and pick the right class inmediately. In your case you still have to browse 100 classlibs to do the same. Your bests case seem to be equivalent to my worst case (All my classlibs are expanded).

>Further, if I am working with a few classes, they will be expanded, and the others will not be expanded, making it clear which classes I'm working with, and making it easier to jump among the classes I'm working with. That may also be a benefit when I return from lunch.

Sorry, but I don´t see that. If you´ve got a few classlibs expanded you still have to browse through 100 + a few nodes. And If I return from lunch and forgot on which classes I was working, I´d look in the command windows which lists the most recently opened classes.

>>I see your point to one extent however, you cannot always regard a class as a LEGO block. sometimes it is more appropriate to look at a classlib as a lego block. Take for example my crystal reports class. I either use or not use crystal reports. If you use it, you will likely need all classes stored in there. I don't see any reason to split this classlib up into one classlib for each class.

>I can agree with that. I'm only saying that the arbitrary collection of classes into classlibs is worse than leaving all classes in separate classlibs.

Well, If you´ve got a few classlibs where all classes are stored in a specific arbitrary classlib, I´d agree. But I don´t think that will ever be the case. Sure, there might be a few classes that could be stored in any (or any of few) classlib, but the ease of inmediately beeing able to drill down to the right class would have an advantage (Crystal Reports Example) is a real pre. Adding advantages and disadvantes up, it might merely go down to personal preferences.

>You stated you have a single classlib with all forms and dialogs. I can see the logic behind the crystal reports class, but not the forms and dialogs class.

Unless they are application specific.

>>Good point. However this only applies where you have to include only one or very few specific classes of a classlib. If this is the case then it probably is calling for beeing seperated. However to do this blindly on all cases is too extreme for me. I'd rather group classes logically. BTW, most of my claslibs are rather small: only up to a few hundred K. The only classlibs that tend to get really big are the application specific ones. Since you never want to reuse them in other projects that problem does not exist there.

>Ah! Here's where things get interesting. I've learned there are few application specific things. A customer form, name, address and phone number, is a recurring thing across multiple applications.

Well that is not my experience, though. I´ve never come into a situation where I could reuse such general forms. Appart fromt he fact that mostlikely the fieldnames are difference (if you have no control over it), I´d rather copy the class than inherit those. Since they are application specific, change for application A, inmediately show up in application B unless you subclass a general static parent class. Since the customers can have different requirements on such form, it can mean more of a maintenance nightmare than it helps you. IMO, applying inheritance for the sake of inheritance is just not worth it.

>I want the possibility of reusing things in the next app and even to reuse things in this app.

I beg to differ here. Reuse for the sake of reuse is IMO a wrong thing to do. Reuse can mean a maintenance nightmare especially when the requirements of that form or class changes for both application A and B in are heading in totally different directions.

I think it is important to note that inheritance is not a design goal on its own. The goal is to minimize development and maintenance efforts with just enough flexibility. Inheritance can be a tool in achieving this, but it might also be a nightmare, in which at the end you have to decide to break it out of the hierarchy.

>>>That vendor would have separated everything out, except that the retrofitting doesn't warrant the change. So a mistake is perpetuated rather than corrected.
>>
>>I think this applies specifically to framework vendors. However I doubt if this applies to the majority of cases up here.

>That may be so, but you're guessing. In either case, the fact that the majority does something does not mean it's right.

Sure, but I don´t see any convincing arguments here that do justify to put every single class into a seperate classlib.

>You are your own framework vendor. You should try to create modules that can be reused and avoid combining things so that they cannot be reused without more work.

I think this should read something like. You should try to minimize development time, time to do maintenance, reduce the number of bugs that can occur and make your source readable to other devleopers so they could have the same development speed as you do.

Again, Inheritance (reuse) plays a role in it, but not exclusively. There are different viewpoints in this. Sometimes over-emphasizing inheritance can do more harm than good. You´ve got to watch out and let common sense rule here.

Walter,