>>Ah but then we'd have to benchmark pure newobject() and no classlibs set vs Set ClassLib/Set Procedure and CreateObject(). If there were none set (and none to reopen) then its speed may be the same.
>
>I often find myself wondering why we focus so hard on this level of detail. Best practice says we're supposed to make a component (UDF or class) to encapsulate design decisions of this kind.
>
>A factory object IMO (being the ultimate in flexibility) should be used to instantiate objects. It would be the place to decide if we should use newobject or createobject - as hardcoding classes limits flexibility.
>
>Further it would be a fantastic place to add code that checks to see if the class / procedure is already opened before opening it again.
>
>IF NOT "VCXNAME" $ SET("CLASSLIB")
> SET CLASSLIB TO VCXNAME ADDITIVE
>ENDIF

I'm glad it came to the issue of factory. IMO, that's exactly where this sort of issue should be solved - you can build your factory to use either (create- vs new-), so your factory.dbf needs or doesn't need library names.

Of course, you still get the same issues I listed in the beginning - do I need to know where does my class reside, do I need to know the hierarchy to be able to debug quickly etc. It's now located in the factory, i.e. you don't have to hunt for references all around your app, which makes it a lot easier.