Stefan

If one works within a framework that is designed to avoid namespace conflicts, and the ADDITIVE clause is used, SET CLASSLIB does provide a very workable environment. Localizing the names to every NewObject() call has the drawback in that some cases lots of lines of code need to be changed instead of a single SET CLASSLIB line.

There are tradeoffs between both ways of doing it. Fortunately VFP is flexible enough to let us choose either alternative as appropriate.

>SET CLASSLIB modifies global state, which is inherently bad if you want to use independent, reusable modules. I think this thread has already demonstrated one drawback.

>At first it would seem that is more flexible to use unqualified names and to rely on SET CLAS, SET PATH, SET DATA etc. pp. to make those names available. However, more flexible it is not. In fact, it creates global dependencies and reduces flexibility because of the global coupling; it also requires you to have precise global control over all names that could possibly clash. For one thing it is impossible to run two versions of the same 'thing' side by side, for another it opens the door for all kinds of Heisenbugs because of the way Fox does name caching internally (especially for class names) and the haphazard fashion in which DBC-related names are resolved. And what happens when you integregate third-party code is anybody's guess ...
>
>Unqualified names can allow some cute tricks but these tricks can become a liability unless you have total control over how the names in question are resolved. Basically this means that such names must at all times be unique within a compilation/runtime environment.
>
>Using qualified and/or local names eliminates these problems. Sometimes this requires application-level glue code to pass some info to (and between) subsystems, especially regarding data paths etc., but stuff like this belongs into an environment/config module anyway.
>
>Note: I am not saying that unqualified and/or global names are bad, but the fewer there are the better.