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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
