Hi Peter,
>Thomas, as I read your words, you don't use this method if the choice is yours, right?

Yes, but at least part of this decision is influenced by personal style.
I tend rearchitect or rearrange parts of app splitted solutions. This way I can keep redundancy down, which is my main target. Think of it as analogous as pushing methods up the inheritance tree, but done for functions living on the stack.

>
>Another problem is not nicely tackled by this workaround: We can't use quotes when using a function. Such a call only goes well if the function is in a library that has been declared with
>

set procedure to ("path\myproc")

Since I set proc regularly, so I haven't checked it, but I'ld assume a
eval("myFunction(tc...)")
to work, and if it isn't in loop's the eval() normally doesn't bother my quest for fast code if there are other benefits.

>I'm sure ( knowing him a little :) that Walter has succeeded tackling all consquences,
If you have a clear idea what you want and are disciplined enough to check the availability of the functions, it works. IMHO the risks grow with multiple developers as well. From what I've read of Walter, I don't doubt his success [even if he has to educate a few other developers], if believes the gains are worth it. But as I read his post, he only mentioned the possibility. Don't know how often he employs it.

>No, the fundamental solution must be laying somewhere within the possibilities of the project manager.

Some schemes come to mind, but probably more work than warranted: building a meta pjx and making sure each part is only added once as "included".

regards

thomas