Hi Stephan, some great work, thanks.
On Thu, 2013-12-19 at 10:51 +0100, Stephan Bergmann wrote: > thought-dump: really helps :-) > * assume all LO-internal C++ implementations are ComponentContext-based > (i.e., use cppu::createSingleComponentFactory or > cppu::createOneInstanceComponentFactory rather than legacy > ServiceManager-based cppu::createSingleFactory or > cppu::createOneInstanceFactory); reaching this state is effectively an > easy hack Yep, but maybe we don't need special easy hack for this. So far, I was able to just remove the variables as unused. I think it's easy to do as part of creating constructor function for implementation. > * implementations of non-single-instance services can be rewritten using > the new .component XML <implementation constructor="..." feature, cf. > <http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae3a0c8da50b36db395984637f5ad74d3b4887bc> > > "Add .component <implementation constructor='...' feature"; this is > effectively an easy hack (note that service manager's > createInstanceWithArguments[andContext] no longer uses the > css.lang.XInitialization protocol on those implementations) Hm, what does it mean, it no longer uses css.lang.XInitialization protocol? What to do about implementations inheriting from XInitialization? I tried to convert such class in https://gerrit.libreoffice.org/#/c/7186/ Does it look good ? If it's clear when to assert for arguments->nElements and what to do about initialize() we should create an easy hack for this I think. > * for implementations of single-instance services/singletons, we can: Sorry, no opinion on this from me. ;-) > ** note that there are always situations where UNO services are not > called via constructor, though; e.g., the constructor-less > css.uri.UriSchemeParser_* services are always created via dynamically > computed name Ah, good to know we need to care about such cases. > * idea is to set aside for every UNO service/singleton S two macros > LO_URE_CTOR_ENV_<S'> and LO_URE_CTOR_FUN_<S'>, and a macro > LO_URE_CURRENT_ENV, and modify cppumaker to generate constructor code as > > > #if defined LO_URE_CURRENT_ENV && defined LO_URE_CTOR_ENV_<S'> \ > > && defined LO_URE_CTOR_FUN<S'> && LO_URE_CURRENT_ENV == > > LO_URE_CTOR_ENV_<S'> > > > > extern "C" cppu::ConstructorFunction_type LO_URE_CTOR_FUN<S'>; Is not LO_URE_CTOR_ENV_<S'> redundant ? We can just check for defined LO_URE_CTOR_FUN<S'> ? > ** when compiling .cxx files for which it is known that the constructor > function for some S will be visible (which could e.g. be ~always the > case when compiling for a single big executable on Android/iOS), define > the LO_URE_CTOR_ENV_<S'> and LO_URE_CTOR_FUN_<S'> macros, either via -D > or via some strategically included header Yes, so this needs some thought. If I see correctly, there are already some typos in 15abebbde560e17413f17b16b8b2e9c1f31f01a5 like LO_URE_CTOR_FUN_com_dot_sun_dot_star_dot_xml_dot_sax_dot_FastParser vs. LO_URE_CTOR_FUN_com_dot_sun_dot_star_dot_comp_dot_extensions_dot_xml_dot_sax_dot_FastParser Unfortunately I can't see how to avoid these macros, so I'll try to generate include/osl/detail/component-defines.h early in build process. Do you have another idea ? Overall, this looks really good, Thanks, Matus _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
