Re: [udk-dev] Unpublished interface to published service
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]
Re: [udk-dev] Unpublished interface to published service
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]
Re: [udk-dev] Unpublished interface to published service
Hi Mathias, On Fri, 2007-07-20 at 10:00 +0200, Mathias Bauer wrote: Alternatively you could remove your new interface from the IDL file again (as I said: old style services are documentation only) or you can design a new, unpublished service and deprecate the old one. This would be a good opportunity to make this service a new style one. :-) To be honest, I didn't know there was such a thing as a new style service. Is there any article, or web page that I can read about how to create a new style UNO service? Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Unpublished interface to published service
Kohei Yoshida wrote: To be honest, I didn't know there was such a thing as a new style service. Is there any article, or web page that I can read about how to create a new style UNO service? http://marketing.openoffice.org/ooocon2004/presentations/friday/shinyhappyuno.pdf presented things like new style services to the world. The Developer's Guide at http://api.openoffice.org/DevelopersGuide/DevelopersGuide.html contains further information. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Unpublished interface to published service
Frank Schönheit - Sun Microsystems Germany schrieb: Hi Mathias, The only way would be to make the service itself unpublished what of course is not allowed also. Perhaps we could allow it for this service as it is an old style service and these services never have been used for anything else than documentation. So making it unpublished won't break any code. But I assume that this would create some hassle. Alternatively you could remove your new interface from the IDL file again (as I said: old style services are documentation only) or you can design a new, unpublished service and deprecate the old one. This would be a good opportunity to make this service a new style one. :-) Sorry, but as even the inventors of new style-services say, they aren't the final solution to every problem, and they cannot be applied to each and everything. So, 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. What in this would be a good opportunity to make this service a new style one makes you believe that I proposed this as the *solution* of the problem? For me it's just a *side effect* of the replacement of the old service by a new one. So *if* a new service needs to be changed for whatever reason it *should* be considered to also make it a new style service. You see the difference? 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. 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. 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]
Re: [udk-dev] Unpublished interface to published service
Hi Kohei, But I'm having trouble leaving the new interface unpublished. I've added the following lines: /** provides access to the collection of filter fields. */ [optional] interface com::sun::star::sheet::XExtendedSheetFilterDescriptor; but the building of offapi fails, noting that you can't use an unpublished interface to a published service. Is there a way to get around this? I heartly disagree with Stephan's answer, but so far was not able to convince him (we already discussed this). http://www.openoffice.org/issues/show_bug.cgi?id=69326, btw, describes the problem - please lobby for it :). In my opinion, the restriction that you cannot add unpublished interfaces as optional entity to published services is way too strict. There are very theoretic (sorry, Stephan) reasons for this, but in reality, all services which are affected by such a change would not suffer at all. Mentionng the new interface in the document only is not a valid alternative, as this introduces an additional complexity in the generated IDL reference, is more easily overlooked by readers, and can't be examined at runtime (see css.reflection.XServiceTypeDescription.getOptionalServices). But, well, you asked for a workaround. I'll tell you one of my best-kept secrets :), though it will probably cease existing now that Stephan knows about it: Just forward-declare the interface, instead of including the IDL, and pretend, in the forward-declaration, it is published. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Unpublished interface to published service
Frank Schönheit - Sun Microsystems Germany wrote: Hi Kohei, But I'm having trouble leaving the new interface unpublished. I've added the following lines: /** provides access to the collection of filter fields. */ [optional] interface com::sun::star::sheet::XExtendedSheetFilterDescriptor; but the building of offapi fails, noting that you can't use an unpublished interface to a published service. Is there a way to get around this? I heartly disagree with Stephan's answer, but so far was not able to convince him (we already discussed this). http://www.openoffice.org/issues/show_bug.cgi?id=69326, btw, describes the problem - please lobby for it :). In my opinion, the restriction that you cannot add unpublished interfaces as optional entity to published services is way too strict. There are very theoretic (sorry, Stephan) reasons for this, but in reality, all services which are affected by such a change would not suffer at all. Mentionng the new interface in the document only is not a valid alternative, as this introduces an additional complexity in the generated IDL reference, is more easily overlooked by readers, and can't be examined at runtime (see css.reflection.XServiceTypeDescription.getOptionalServices). But, well, you asked for a workaround. I'll tell you one of my best-kept secrets :), though it will probably cease existing now that Stephan knows about it: Just forward-declare the interface, instead of including the IDL, and pretend, in the forward-declaration, it is published. mmh, that is of course a bad hack. If we would extend regcompare to detect this as well the build would fail again. I don't like this approach. Either we find an agreement that it is allowed or we shouldn't do it. So please don't do it this way at the moment. Juergen Ciao Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Unpublished interface to published service
Kohei Yoshida wrote: Hi there, I'm in the process of extending Calc's standard filter API to cover new types of filters. In doing so, I will need to add a new interface to an existing UNO service (css.sheet.SheetFilterDescriptor), but I'd like this interface to stay unpublished until this API stabilizes. But I'm having trouble leaving the new interface unpublished. I've added the following lines: /** provides access to the collection of filter fields. */ [optional] interface com::sun::star::sheet::XExtendedSheetFilterDescriptor; but the building of offapi fails, noting that you can't use an unpublished interface to a published service. Is there a way to get around this? The only way would be to make the service itself unpublished what of course is not allowed also. Perhaps we could allow it for this service as it is an old style service and these services never have been used for anything else than documentation. So making it unpublished won't break any code. But I assume that this would create some hassle. Alternatively you could remove your new interface from the IDL file again (as I said: old style services are documentation only) or you can design a new, unpublished service and deprecate the old one. This would be a good opportunity to make this service a new style one. :-) 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]
Re: [udk-dev] Unpublished interface to published service
Hi Mathias, The only way would be to make the service itself unpublished what of course is not allowed also. Perhaps we could allow it for this service as it is an old style service and these services never have been used for anything else than documentation. So making it unpublished won't break any code. But I assume that this would create some hassle. Alternatively you could remove your new interface from the IDL file again (as I said: old style services are documentation only) or you can design a new, unpublished service and deprecate the old one. This would be a good opportunity to make this service a new style one. :-) Sorry, but as even the inventors of new style-services say, they aren't the final solution to every problem, and they cannot be applied to each and everything. So, 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. We need a working solution for this. Currently, it are hassles like those which alienate even the good-will developers which actually *do* try to write good API documentation (it are way too few). If we're serious about our API, we shouldn't impose such artificial restrictions on ourselves. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [udk-dev] Unpublished interface to published service
Hi Juergen, But, well, you asked for a workaround. I'll tell you one of my best-kept secrets :), though it will probably cease existing now that Stephan knows about it: Just forward-declare the interface, instead of including the IDL, and pretend, in the forward-declaration, it is published. mmh, that is of course a bad hack. If we would extend regcompare to detect this as well the build would fail again. Well, your comment in the mentioned issue reads accepted, so I thought that my small, little, innocent hack :) just anticipates your resolving of the issue :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
