>>So what I would do is in addition to my Get/Set methods I would do a CheckGlobal() or something similiar to handle the prelim 'does it exists?' question. I guess the extra method still adds complexity but I think I would rather have to remember an extra method name as opposed dealing with the visibility issue in both Get() and Set(). What do you think?
>
>I like it, I should also point out that it'd be wise to have a Remove() method as well, incase you store an object reference in it that needs to be removed.

Yes! and of course a Store() to put global in collection to begin with.
>
>Of course, all of this leads me to conclude that we should be talking about oApp.oGlobals rather than a property array, so that the application object's UI doesn't get clouded with all of the methods related to the globals collection.

My thoughts exactly... if we're going to address alleviating complexity with additional functionality, then your oGlobals alternative in original suggestion is the best bet. Which also fits nicely then if developer goes the route addressing of another point in this thread with either the Command Class you mentioned or the Proxy Arnon mentioned. End result being oApp gets streamlined and responsibilities offset via composite object/aggregation! Boy, I just love this!