[Libreoffice] minor idl fixes

[Stephan Bergmann]

On 04/20/2012 12:42 AM, Tomas Hlavaty wrote:
> 1) Exceptions have message and context fields and there should be a
>     constructor with arguments (java.lang.String m, java.lang.Object c)
>     for those fields.  However, this doesn't seem to be applied
>     consistently.

Where is this not applied consistently?

> Also when an exception inherits, it should have a
>     constructor with all fields for the super classes and itself.
>     However, the context field is missing in such cases.  Is there some
>     rule to this or is it arbitrary?

Looking at handleAggregatingType in 
codemaker/source/javamaker/javatype.cxx, for an exception three <init> 
methods (i.e., constructors) are generated, one with no parameters, one 
with just a String parameter (to be consistent with Java's overall 
Exception design), and one with parameters for all the (inherited and 
direct) members.

> 2) What is the meaning of 'published' in idl files?  It seems to be
>     ignored in javamaker, or at least everything gets generated no matter
>     what.  For example, there are enums or constants which are not marked
>     as published but other public symbols depend on them.  Shouldn't
>     those be public too then?

See slide 15 "Published Things" of the presentation 
<http://www.openoffice.org/marketing/ooocon2004/presentations/friday/shinyhappyuno.pdf> 
"Here Come UNO, All Shiny and New" for a short description of 
"published" (more extensive documentation appears to be lost to the 
Internet).

That a published entity does not use unpublished entities is already 
checked by idlc, so the codemakers can ignore it.

> 3) What is the meaning of simgleton referring to service referring to
>     interface?  In the example bellow, the BrowseNodeFactory service
>     doesn't seem to be generated from idl files.  Should this service be
>     bypassed and the singleton reffer directly to the interface?

Old-style singleton specifications are indeed somewhat obscure.  The 
need for a service is due to old implementation/design artefacts. 
New-style singleton specifications directly specify the interface they 
support, without going any service detour:

   singleton theBrowseNodeFactory: XBrowseNodeFactory;

Stephan