strepsirrhini/office-gobmx
9
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
office-gobmx/stoc
History
Stephan Bergmann 5687eba49f Drop obsolete preprocessor directives from UNOIDL files 
...which were used by ildc, which is gone since
a8485d558f "[API CHANGE] Remove deprecated idlc
and regmerge from the SDK", and have always been ignored as legacy by its
unoidl-write replacement.

This change has been carried out (making use of GNU sed extensions) with

> for i in $(git ls-files \*.idl); do sed -i -z -E -e 's/\n\n((#[^\n]*\n)+\n)*(#[^\n]*\n)+\n?/\n\n/g' -e 's/\n(#[^\n]*\n)+/\n/g' "$i"; done && git checkout extensions/source/activex/so_activex.idl odk/examples/OLE/activex/so_activex.idl

which apparently happened to do the work.  (The final two files are not UNOIDL
source files.)

Change-Id: Ic9369e05d46e8f7e8a304ab01740b171b92335cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135683
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-06-13 16:27:45 +02:00
..
source [API CHANGE] Deprecate css.registry.XSimpleRegistry::mergeKey 2022-06-11 09:58:49 +02:00
test Drop obsolete preprocessor directives from UNOIDL files 2022-06-13 16:27:45 +02:00
util
CppunitTest_stoc_uriproc.mk Fix test dependencies for module-only build 2019-08-19 12:50:01 +02:00
IwyuFilter_stoc.yaml tdf#42949 Fix new IWYU warnings in directories s* 2020-12-01 14:56:43 +01:00
Library_bootstrap.mk URE Library_boostrap should not depend on Library_comphelper 2022-05-09 17:58:29 +02:00
Library_introspection.mk Generally determine Rdb content from gb_*_set_componentfile calls 2021-12-10 08:14:24 +01:00
Library_invocadapt.mk Generally determine Rdb content from gb_*_set_componentfile calls 2021-12-10 08:14:24 +01:00
Library_invocation.mk Generally determine Rdb content from gb_*_set_componentfile calls 2021-12-10 08:14:24 +01:00
Library_javaloader.mk Don't use Library_tl in URE libraries 2022-02-25 08:20:55 +01:00
Library_javavm.mk Don't use Library_tl in URE libraries 2022-02-25 08:20:55 +01:00
Library_namingservice.mk Generally determine Rdb content from gb_*_set_componentfile calls 2021-12-10 08:14:24 +01:00
Library_proxyfac.mk Generally determine Rdb content from gb_*_set_componentfile calls 2021-12-10 08:14:24 +01:00
Library_reflection.mk Generally determine Rdb content from gb_*_set_componentfile calls 2021-12-10 08:14:24 +01:00
Library_stocservices.mk Generally determine Rdb content from gb_*_set_componentfile calls 2021-12-10 08:14:24 +01:00
Makefile fix makefiles 2012-04-06 16:49:20 +02:00
Module_stoc.mk Re-enable stoc/test/uriproc/ 2019-08-16 19:44:33 +02:00
README.md Updated README.md files to represent current code / use Markdown format 2021-04-07 17:47:16 +02:00
unosdk.mk re-base on ALv2 code. 2012-06-21 13:11:06 +01:00

README.md

Registries, Reflection, Introspection Implementation for UNO

The UNO types and services bootstrapping code is very old, and concepts are tightly knit together. Whenever you want to change something you risk backwards incompatibility. The code causes mental pain, and whenever you need to touch it you want to run away screaming. One typically ends up doing minimally invasive changes. That way, you have a chance of surviving the process. But you also pile up guilt.

At the heart of the matter there is the old binary "store" file structure and the XRegistry interface on top of it. At runtime, both all the UNO type information (scattered across a number of binary .rdb files) and all the UNO service information (scattered across a number of .rdb files that used to be binary but have been mostly changed to XML now) are represented by a single XRegistry instance each.

The way the respective information is represented in the XRegistry interface simply corresponds to the way the information is stored in the binary .rdb files. Those files are designed for storage of hierarchically nested small blobs of information. Hence, for example information about a UNO interface type com.sun.star.foo.XBar is stored in a nested "folder" with path com - sun - star - foo - XBar, containing little blobs of information about the type's ancestors, its methods, etc. Similarly for information about instantiable services like com.sun.star.baz.Boz.

As there are typically multiple .rdb files containing types resp. services (URE specific, LO specific, from extensions, ...), but they need to be represented by a single XRegistry instance, so "nested registries" were invented. They effectively form a linear list of chaining XRegistry instances together. Whenever a path needs to be looked up in the top-level registry, it effectively searches through the linear list of nested registries. All with the cumbersome UNO XRegistry interface between the individual parts. Horror.

When the XML service .rdbs were introduced, we chickened out (see above for rationale) and put them behind an XRegistry facade, so that they would seamlessly integrate with the existing mess. We postponed systematic clean-up to the pie-in-the-sky days of LibreOffice 4 (or, "once we'll become incompatible with OpenOffice.org," as the phrase used to be back then)