Joerg Barfurth wrote: > 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. That's not true. Documentation also contains text, not only IDL syntax. There's nothing that prevents you from adding information like "this service may optionally support the interfaces XFoo and XBar".
The possibility of "old style" services to add IDL syntax expressing this directly is only convenience - no code and no type information was created from that. If that wasn't the case the misuse of the "optional" keyword in old style services wouldn't have been possible (see below). > 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. Multiple inheritance interfaces also can have "optional" interfaces! We should differentiate here between two use cases for "optional": (1) "real" optional interfaces that the service and interface designer intentionally wanted to have as an optional facet of objects implementing the service. This is possible for new style services also as their multiple interface interface can have optional interfaces. Stephan should be able to explain that in closer detail but as I understand it, "optional" still is "documentation only" but now the UNO type system and tooling ensures that new optional interfaces can't be added without creating a new type what IMHO is a good thing(see below). Again MI interfaces replace "old style" services! (2) interfaces "forgotten" in a service description in the first place that have been added later on. Strictly spoken this is an ugly hack as the type is changed incompatibly and it just didn't create problems because it is "documentation only" and no code or type information was created for it. It would have been better to create a new service name for the new combination of interfaces. This hack is not possible in for MI interfaces as (different to "old style" services) we enforce the compatibility of interfaces. So the "new style" service concept now enforces the proper use of the "optional" keyword - IMHO nothing that can be seen as a disadvantage (except if lazyness is important). > 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. Maybe I don't understand where you are aiming at. What prevents you from registering more than one implementation for a "new style" service? You could treat them the same way as your old style services. Please explain. > 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. That's a misuse IMHO. But you can continue this misuse by defining a "new style" service implementing a MI deriving from XInterface only and again defining all other interfaces as "optional". Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
