Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Is one concrete Class per Class Lib a poor/good idea?
Message
From
14/07/2004 16:58:57
Mike Yearwood
Toronto, Ontario, Canada
 
 
To
14/07/2004 15:57:57
Charlie Schreiner
Myers and Stauffer Consulting
Topeka, Kansas, United States
General information
Forum:
Visual FoxPro
Category:
Classes - VCX
Miscellaneous
Thread ID:
00916585
Message ID:
00924391
Views:
46
Good to hear! I certainly don't think the classlibs and procedure libraries are a good organization tool. What I've done is break things down, making them atomic and always looking to make useful components, even the parts of components can be useful. I do get to use them in other projects.

>Hi Mike,
>I just wanted to comment on your 'lots of little files' concept. I like it, and wish I had used it a bit more. (It's a pain to change too much now.) I have used the concept with PRGs in the past, but not as extensively on VCXs.
>Just as an example, I work regularly with about 5 applications. Each one has about 43 VCXs, holding about 700 classes. There are over 150 prg files. Since we are involved in the same application domain in each of these applications, they almost all use most of the same files. The only difference between each application is metadata and lots of subclasses that change the behavior of the base classes. I tend to put all the app specific subclass code in two files: a prg and vcx. That works fine. However, lately I've created more and more base classes that hold only one class or perhap more, but ones that are all to be used together. So when it comes time to build an EXE, I only get the code I need. As I say, I wish I had done that even more.
>
>
>
>>>>Core may be the wrong word. I'm referring to functions that are atomic, like ISARRAY. It doesn't really belong anywhere, because it could be used in so many places.
>>>
>>>Theoretically I think you're right. However practically it seems more of a hassle as you'll end up with many, many prgs in your project cluttering up your PM (given the fact we cannot classify functions and classes in the PM). Let's be honest, if you were to design a prg with the most common atomic functions in there how many KB will that take?
>>
>>Size is irrelevant, so you can't use that as an argument. I'm more concerned with the difficulty of learning which PRG holds which functions. You say I'm cluttering up the PM with PRGS and I say you're cluttering up a PRG with procedures and functions. We're continuing to disagree about how they are organized. So let's get rid of the problem. We need a better way to categorize components while working, and a way for the project manager to have all the components it needs.
>>
>>>>I don't think we should just dream. We can make it happen. That is your signature after all.
Previous
Reply
Map
View

Click here to load this message in the networking platform