[Libreoffice] minor idl fixes

[Stephan Bergmann]

On 12/13/2011 01:21 AM, Tomas Hlavaty wrote:
> Stephan Bergmann<sbergman at redhat.com>  writes:
>> At runtime, the C++ UNO binding queries the types.rdb for certain data
>> (e.g., when (un-)packing data as ANY).
>
> OK.  Does it need to go through the rdb file?  It could as well be
> already compiled into a dll.

Yes, but duplicating information has disadvantages.  The main problem 
that I see here is .oxt extensions that bring along additional UNO 
types.  If a UNO language binding relies on runtime type information 
being available in any format other than the common .rdb format, each 
such extension needs to include that language-specific data alongside 
its common .rdb data.  This is a burden for extension developers, and 
does not scale with the introduction of new language bindings.  The Java 
way of relying on Java .class files instead of .rdb has been identified 
as a mistake.

>> Binding UNO to dynamic languages like Python takes another approach.
>> It obtains any necessary information purely at runtime, from the
>> types.rdb, via UNO services that make available that information.  It
>> does not require any *maker tool to generate language-specific
>> artefacts from the complete type information upfront.
>
> OK.  But it could be made faster if the type information was available
> in one go instead of querying per instance, if the speed was a problem?
> So we could have the type information in a readable format or generated
> as a py file.  Or maybe everybody is happy with the way python does it?

I think the less one needs to generate upfront, the easier the overall 
workflow becomes.

> What about StarBasic?  I guess that would be similar to Python.

Yes, it mainly uses a UNO invocation service that obtains a UNO object 
reference, name of what to invoke (interface function, property 
setter/getter), and arguments, and handles all the minute details 
internally.

>> Another point to re-evaluate is how much of that complete type
>> information to duplicate in the artefacts generated for the various
>> language bindings.
>
> Why not all?  It's not that much.

See above.

>> On the one hand, it might be advantageous to encode more information
>> in the generated C++ artefacts (potentially even generating a
>> dedicated dynamic library containing the relevant, instead of
>> spreading it inlined across header files, where the linker can
>> recombine part of it again). That could help ensure that the
>> (new-style) types.rdb need not be read early on during startup (so if
>> loading it where somewhat costly that would not be that much of a
>> problem as it is today).
>
> Yes.  But wouldn't be the type database still required as C++ doesn't
> have the reflection capability built-in?

Yes, of course.  This would purely be a performance improvement, with 
the trade-off of duplicating information for speed.  (And as all 
information would still be available in .rdb, this would have no 
implications for extensions.  Whenever information about a type is 
needed for which there is no "statically cached" direct C++ data, the 
language binding would fall back to the---slower---.rdb data.)

>> On the other hand, an easily parsable format would allow Java to
>> reduce the amount of information currently stored in generated .class
>> files, and instead rely on the complete type information available as
>> a (new-style) types.rdb.  Java .class files could even be generated on
>> the fly from the types.rdb information using a dedicated Java class
>> loader. (That would remove the ugly requirement that .oxt extensions
>> need to bring their additional UNO types as both .rdb and .class
>> files.)
>
> Here I don't know how these .oxt extensions work.
>
> Is the size of generated .class files an issue?

No, see above.

>> Though idlc, climaker, javamaker, codemaker would "just" be replaced
>> with your new code (that conceptually does the same thing), if I get
>> you right?
>
> Exactly;-)

But why rewrite climaker, javamaker, codemaker then?  As they take their 
information from the interface abstracting from the actual .rdb format, 
they can be left unchanged (or enhanced to emit additional information, 
if so desired).

>> (Note that module idl is completely unrelated to UNO.)
>
> What is it then?  It looks like something related to idl compilation.

That other idl describes user interface resources.

Stephan