>>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.
>
>Well, you could subclass the project manager which copies the resource from a repository into a subdir of the application and build the application from there. However, I'm not sure how to copy changes of any item in the PM into the repository again.
>
>I think this need a lot of thoughts before implementing. But you might be right, this beeing possible.

I don't understand the reference to subclassing the project manager. I think we'd have to create a new UI that would replace the project manager. It would have to create a project on the fly to build an exe though.