Re: Efficient UNO component linkage & GC ...

Some notes on recent changes around constructor functions:

* The change of 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=306efefe22e02248eff14f8be2cef68d75d26e55> 
"Minimize the constructor functions to a bare minimum" to let 
constructor functions return un-acquired pointers breaks constructor 
functions that internally already have an acquired pointer.  This includes:

** Constructor functions for singletons, like 
com_sun_star_comp_sfx2_GlobalEventBroadcaster_get_implementation 
(sfx2/source/notify/globalevents.cxx).

** "Wrappers" like those for which constructor functions have been 
reverted again in 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=9bc2ab30e302c210b725e7035ea4d17774ef90e1> 
"Revert 'svt: Use constructor feature for FilePicker and 
FolderPicker...'" (based on the rationale it "does not make a real sense 
to use constructor for implementations that act as a trampoline," which 
I do not understand).

If the stated rationale for that change is that it is "annoying to see 
the boilerplate copypasted everywhere," I think there is better 
solutions for that, like providing a helper function to be called from 
the typical constructor function,

  css::uno::XInterface * acquire(cppu::OWeakObject * instance) {
    assert(instance != 0);
    instance->acquire();
    return instance;
  }

  css::uno::XInterface * FOO_constructor_function(...) {
    retrun acquire(new FOO(...));
  }

* 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=f278397787f7b79cee8536e806e8b7113800f2ef> 
"Change _get_implementation()'s not to do initialization directly" makes 
it more awkward to code the (assumedly) common case where a UNO service 
constructor with arguments can be implemented directly by a C++ class 
constructor with arguments.  That change forces two-step construction, 
via passing back a member function pointer, onto all such cases, with 
the apparent rationale to make the (assumedly) non-common case that does 
require two-step construction simpler to code.

(And I'm not even sure it is technically correct to force the address of 
a member function of a class derived from cppu::OWeakObject to 
cppu::constructor_InitializationFunc.  Also, for the static_cast from 
XInterface to OWeakObject in servicemanager.cxx to work, this change 
makes the---undocumented---requirement that constructor functions making 
use of the two-step--init callback return an exact one of their 
potentially many XInterface pointers; rather brittle.)

FYI, I envisioned a road where ultimately a (new-style) UNO service's 
different constructors rather directly map to a C++ implementation 
class's different constructors.

* One main reason for introducing those constructor functions in the 
first place is to allow (in specific scenarios) for direct calls of them 
from client code, bypassing the service manager.  I think it is 
beneficial to test that direct-call scenario as much as possible while 
working on this, that is why I created the manual scaffolding of 
osl/detail/component-defines.h. 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=921e2dc0393873ad0a972252000803ceadc290cb> 
"Reduce the number of experimental direct constructor calls" reducing 
instead of increasing the number of constructor function implementations 
for which direct-calling will actually be tested is detrimental to that.

Stephan