>Hi,
>
>In a recent discussion with another developer, we were debating coding style and application architecture for a new project. We hit upon something that neither one of us knew for sure whether we were just debating a philosophical issue or whether there were technical issues at stake. So I thought I'd throw it out here and see if anyone has some insight on this.
>
>I should mention that one of the goals is to accomodate multiple developers and have the least amount of contention as possible on the source files. So we thought putting each class in its own .PRG file would be a smart thing to do. This strategy could be altered slightly to put a moderate number of classes into the same .PRG if they are closely related. But either way, we are likely to have hundreds of .PRGs containing nothing but classes.
>
>So the question is...
>When we build the app, is it better to have many hundreds of SET PROCEDURE TO statements to load the classes, or would it be better to create a pre-compile project hook that would copy these individual classes from their source files and place them into one (or a few) resulting .PRG file(s) and only have a small number of SET PROCEDURE TOs in the app?
>
>Any thoughts? Are there performance trade-offs? Other technical concerns? Or is this just a matter of personal preference?
>
>Guy

IMHO personal preference. I have many classes in many prgs. PRGs group classes by functionality (ie: data related ones are all in one dataclass.prg)
I instantiate classes (VFP6 and later) :
oMyClass = NewObject(ClassName,ClassLibPrg,'',Paramlist)
rather than 'set proc to'.
Cetin