Hi,
I just found this when browsing accumulated mail after vacation, so
warming up this old thread.
I just want to second the position that there are things that have been
done using old-style services, which can't be done using new-style services.
Mathias Bauer schrieb:
Alternatively you could remove your new interface from the IDL file
again (as I said: old style services are documentation only) [...]
[...], what you suggest is not a viable option, as there
are enough old-style services around which cannot be reasonably
converted to new-style ones.
I just asked for checking *if* a new service that should replace or
complement an old one also could be a "new style" service. Alternatively
the new service derived from the old (and "old style") service could
also be extended and converted to a multiple inheritance interface as
IMHO this is the better alternative and covers everything you can get
from an "old style" service except the service name.
It doesn't (see below).
I don't see any "old style" service that can't be converted to a
multiple inheritance interface. In case it still should be made
available as a service so that it can be instantiated by a service
provider it can also become a "new style" service. In case you still
need an "old style" service (for what?) it also can be based on the
multiple inheritance interface.
No. One of the things you don't get is optional interfaces. I have to
admit that these are documentation only, but there is no place else to
put this documentation. If you have several optional interfaces,
creating multiple inheritance interfaces for all possible combinations
is not feasible. Besides the combinatorial problem, you may actually
want a single service name for this flexible class of objects. I know
services where the actual set of interfaces supported is chosen when
they are created, according to runtime conditions (for example
controlled by values read from UNO context or configuration files). In
this case having a single constructor for the service, as new-style
services offer, would actually be nice, but the restriction to a single
MII prevents that (it would at least lose a place for documenting the
possible permutations and their semantic relationsships in a way that
can be discovered by introspection tools and that leads to proper
cross-references in generated documentation.
Another case is where a service name is used not to request instatiation
of a single object - as an instance of the (or a) registered
implementation, but to enumerate all registered implementation and to
instantiate all of them (possibly after some additional filtering). This
enumeration feature appears to be gone completely from the new-style
service concept. IIRC there is a case where an old-style service
intended for this use can optionally implement one of several interfaces
(might be "services" that here correspond to MI interfaces) with so
little overlap, that the corresponding MII interface would be empty.
[Admittedly the constraint that at least one of these interfaces must be
implemented can't be expressed in IDL - not even in the old style
service construct, so it is documentation only.]
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
