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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
