Re: constructing services

[Stephan Bergmann]

Frank Schönheit - Sun Microsystems Germany wrote:

> 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.

Those services *are* instantiated at the global service manager.  It is
only that they are not typically instantiated with a statically known
name (where xyz.create is superior to smgr.createInstance("xyz")), but
rather with a computed one (where xyz.create would be of no use, at
least in your typical UNO language binding).  Again, take a look at the
UriReferenceFactory example.

>> 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.

The simple UNOIDL syntax "service Service: Interface;" does cause
default constructors to be generated.  Do you know any cases where
inadvertently the special-case syntax "service Service: Interface {};"
was used instead?  Maybe we can still fix those.

> 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 ...

The idea was to move service instantiation into the language bindings
(so, e.g., in C++ a class implementing a service would probably have C++
class constructors matching the UNO service constructors, or static
factory methods, etc.).  The current XImplementation stuff is seen as a
gross hack to implement service constructors (at least by me).

Unfortunately, this somehow keeps slipping on the urgent todo list...

-Stephan

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

[Frank Schoenheit, Sun Microsystems Germany]

Hi Stephan,

> Those services *are* instantiated at the global service manager.  It is
> only that they are not typically instantiated with a statically known
> name (where xyz.create is superior to smgr.createInstance("xyz")), but
> rather with a computed one (where xyz.create would be of no use, at
> least in your typical UNO language binding).  Again, take a look at the
> UriReferenceFactory example.

Ah, I didn't understand that you were aiming at the URI scheme parsers,
not their factory. Got it now, thanks :)

> The simple UNOIDL syntax "service Service: Interface;" does cause
> default constructors to be generated.  Do you know any cases where
> inadvertently the special-case syntax "service Service: Interface {};"
> was used instead?  Maybe we can still fix those.

No, I don't know them. I just tried to construct a pretty round-about
argument that a) people seem to know constructors too little b) if they
knew, they would use new-style services more often (as this noticably
decreases overhead when constructing such services) c) such subtle
differences might repel people from using them.
Anyway, not really a big deal, as said, just slightly unexpected.

> The idea was to move service instantiation into the language bindings
> (so, e.g., in C++ a class implementing a service would probably have C++
> class constructors matching the UNO service constructors, or static
> factory methods, etc.).

That's something I didn't dare to suggest :).
Moving the ctor handling to the factories, instead of the current
"always default-construct and then late-initialize" would be even
better. For instance, implementations can get rid of all their "not
initialized" handling, in case somebody creates them bypassing the
explicit ctors, and does *not* subsequently initialize them.

> The current XImplementation stuff is seen as a
> gross hack to implement service constructors (at least by me).

+1

> Unfortunately, this somehow keeps slipping on the urgent todo list...

Sad enough. Whenever I implement constructors, I find it pretty ugly to
do all this manual initialization coding.

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@...

[Stephan Bergmann]

Frank Schönheit - Sun Microsystems Germany wrote:
> Hi Stephan,
[...]

>> The idea was to move service instantiation into the language bindings
>> (so, e.g., in C++ a class implementing a service would probably have C++
>> class constructors matching the UNO service constructors, or static
>> factory methods, etc.).
>
> That's something I didn't dare to suggest :).
> Moving the ctor handling to the factories, instead of the current
> "always default-construct and then late-initialize" would be even
> better. For instance, implementations can get rid of all their "not
> initialized" handling, in case somebody creates them bypassing the
> explicit ctors, and does *not* subsequently initialize them.
>
>> The current XImplementation stuff is seen as a
>> gross hack to implement service constructors (at least by me).
>
> +1
>
>> Unfortunately, this somehow keeps slipping on the urgent todo list...
>
> Sad enough. Whenever I implement constructors, I find it pretty ugly to
> do all this manual initialization coding.

See <http://www.openoffice.org/issues/show_bug.cgi?id=75053>, also at
<http://wiki.services.openoffice.org/wiki/Uno/To-Dos#Features>.

Hope that helps  :)
-Stephan

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