Hi Stephan,
On Mon, 2013-12-23 at 18:44 +0100, Matúš Kukan wrote:
> > * 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>
> >
I'm concerned that we already have way too many, far too verbose XML
files, with over-lengthy attributes (some with un-necessary and
over-complicated namespacing to boot ;-). Parsing that lot takes a very
considerable chunk of startup time, and storing redundant foo in memory
seems a bit un-necessary :-)
What does this:
<implementation name="com.sun.star.comp.graphic.GraphicRendererVCL"
+
constructor="com_sun_star_comp_graphic_GraphicRendererVCL_get_implementation">
<service name="com.sun.star.graphic.GraphicRendererVCL"/>
</implementation>
win us over:
<implementation name="com.sun.star.comp.graphic.GraphicRendererVCL"
direct="1">
<service name="com.sun.star.graphic.GraphicRendererVCL"/>
</implementation>
? :-) Certainly the latter can be stored as an extra boolean.
Given that we can trivially produce the symbol name from the
implementation name at run-time ? [ if we even need to produce it at all
- since we can link that at compile time ? :-].
I guess - if this would only ever be used for bits of code that are
going to be in the main mergelibs domain & thus could be directly linked
and evaporated away at compile time: and assuming that we subsequently
avoid those being registered in services.rdb I guess it's no issue:
beyond lots more typing, and scope for typos/errors :-)
I suspect though that mergelibs will not encompass all components
though, and that thus we'll end up with lists of this duplication around
the place still (?).
ATB,
Michael.
--
michael.me...@collabora.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
