On Mon, 2014-01-06 at 16:45 +0100, Stephan Bergmann wrote:
> > ? :-) Certainly the latter can be stored as an extra boolean.
>
> There is a mismatch between the grammar for UNO implementation names and
> C function identifiers usable for these constructor functions, and the
> constructor argument in its current form caters for that.
Is there a practical example of this anywhere ? and/or can we not
default to doing the efficient thing and have the casual bloat version
as a fallback ? ;-)
> Note 1: Of course, "given that we control the [relevant] impl names, we
> [could] simply mandate that they are legal C function names to begin with."
Are the impl. names not exposed to the scripter / programmer ?
> Note 2: "In addition to having [the components data] stored as XML
> files that are parsed at start-up in cppuhelper::ServiceManager::init,
> one could optionally have them pre-compiled into some data structure
> that is accessible from cppuhelper/source/servicemanager.cxx."
Sure; so - if we have that data around in a structure, it'd be great
not to duplicate it in the XML and also in the C++ :-) it'd be nice to
have the strings in one DSO only - if we even need them at all :-) [ are
they just a mapping detail ? ].
> Note 3: A key insight is that "we can easily extend the components XML
> schema, even removing features again in a later LO version." First make
> it work, then make it fast (if necessary).
Sure - my concern is that before we push this across the code-base,
it'd be nice to rid ourselves of the factory functions and come up with
something that is efficient, minimal, as simple as possible, and -then-
push it over a thousand+ call-sites / XML entries etc. Rather than for
each small change having to manually re-touch all that lot.
ATB,
Michael.
--
michael.me...@collabora.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
