Re: IDL syntax

[Stephan Bergmann]

Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Stephan,
>
>>> service DocumentInfo: XDocumentInformation
>>> {
>>> };
>> This syntax would mean that language mappings do no offer default
>> constructors for that service.  Is that intended, or is it a typo
>> (dropping the "{}" would enable the default constructors)?
>
> Uh - I wasn't aware of this. I doubt any developer coming from the C++
> side would expect such a subtle difference. Wouldn't it make sense to
> always generate default constructors?

Too subtle, admitted.  The idea behind it was that there are special
cases of services that are normally not instantiated explicitly (for an
example of this, see the UNOIDL documentation of
com.sun.star.uri.UriReferenceFactory) for which the ability to suppress
constructors would be handy.  While an unfortunate gotcha, I hope it is
not a too problematic one (apart from frustrating authors of new UNOIDL
every now and then), as it should always lead to very visible errors,
not subtle ones.

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Stephan,

>>Uh - I wasn't aware of this. I doubt any developer coming from the C++
>>side would expect such a subtle difference. Wouldn't it make sense to
>>always generate default constructors?
>
> Too subtle, admitted.  The idea behind it was that there are special
> cases of services that are normally not instantiated explicitly (for an
> example of this, see the UNOIDL documentation of
> com.sun.star.uri.UriReferenceFactory) for which the ability to suppress
> constructors would be handy.

Hmm. IIRC, when the the new-style UNO services introduced, it was said
that nowadays, services do not merely describe a collection of
functionality anymore, but the keyword "service" now is (only) for
components which can be instantiated at the global service factory
(which is a too fuzzy term here, I know).
How does this match the idea of services which should not be
instantiated explicitly? /me is confused.

> While an unfortunate gotcha, I hope it is
> not a too problematic one (apart from frustrating authors of new UNOIDL
> every now and then), as it should always lead to very visible errors,
> not subtle ones.

Given that service constructors aren't known very well (at least it
seems to me that some newly introduced services which could have them
actually don't have them for no apparent reason), I suppose an
always-generated ctor would give the ctors more attention, but yes, it's
not really a big problem.

And while we are at it:
Are there any plans to add more explicit implementation support for
constructors? That is, currently a ctor is implemented by using
XInitialization with a sequence of Anys. This imposes certain
limitations, for instance you cannot use two ctors with the same
signature, since your XInitialization::initilize implementation cannot
distinguish them.
Also, implementing a number of ctors (more than one default ctor, that
is), is pretty cumbersome, IMO.

I'm not sure how to best address this, but some interface, to be
implemented by the component, which allows passing the ctor name, plus
the parameter names, would be handy.

  XComponentConstruction
  {
    construct( string CtorName, sequence< NamedValue > Arguments );
  };
, or something like this ...

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...