Department Linux&Office Migration wrote: > 2005/5/12, Mathias Bauer <[EMAIL PROTECTED]>: >> >> Anyway, in all cases (no documentation, derived or versioned services) >> you need to use queryInterface to get the desired interface and you need >> to check the return value, > > Technically yes, but in practice there's no point to doing the check, > because there's nothing my application can do to recover if it fails. > Whether my application exits with a NullPointerException or with an > error message "Sorry, but the OO developers have made an incompatible > change, so this program will no longer work." is solely a matter of > aesthetics. For the user the only thing that matters is that the > program has stopped working after updating to a new OO version.
To make it clear: the non-availability of an optional interface is *not* an incompatibility. It is a concept that optional things are, well, optional and so it is possible that they aren't available. The concept of optional interfaces was "invented" for exactly the reason to avoid incompatibilies in environments where flexibility is needed (because the API is allowed to develop over time). If your program crashes because an optional interface is not available I would see this as a severe defect. If a document doesn't support this interface XScriptProvider the client code at least could behave the same way as if the document supports the interface but doesn't have any scripts available (or doesn't allow to insert scripts). It's also possible to throw an exception and handle it somewhere above and show an error message. Of course you can argue what "in practice" might work, but it's our duty to document and tell what is right and what is wrong. And it is wrong not to check the availability of an optional interface, even if it works without the check in most cases. Do you really never do security checks in your program, even if the documentation tells you that it's possible that NULL is returned by a method, but you never got a NULL pointer back in the last 3 years? > But is this likely to happen? Will office documents in OO 2.1, 2.2,... > 3.0, 3.1 no longer support XScriptProviderSupplier? I doubt it. Of course our documents will continue to support it. But these are *implementations*, and what we document are *services*, and there is no guarantee that any possible new future implementation of this service will support this interface. Services can be implemented by everyone! Of course this is unlikely to happen in this particular case. But we don't document "this interface has an availability probability of 98.6% (so your crashing probability if you don't check the availability will be 1.6%)", we have to document facts. And fact is that it is *possible* (with any probability) that an implementation of an OfficeDocument service doesn't support the interface XTypeProvider. BTW: due to the lack of a working UNO API to the most common crystal ball implementations we can't give "availability probabilities" even if we would like to do so. :-) > If there's no way to document this at the moment, that's a > shortcoming of the IDL that may be worth fixing. Rather than having > an interface "mandatory" or "optional" there could be a versioned > property such as "mandatory since UNO version x.y". This is a misconception on your side. The version of a UNO type is not necessarily bound to a version of UNO or a version of the Office program. Besides that type versioning indeed is one method to fix the problem on documentation side, the others are creating derived services or documentation of implementations, But all of them wouldn't help you: there's always something you need to check at runtime by querying the object, either for the supported services or their versions or the implementation name - or (as you must do it now) you check the interface availability through queryInterface. As an example, we might have documented that a particular API call (let's say loadComponentFromURL) returns an interface to an object implementing css.document.OfficeDocument. Here the XScriptProvider interface is optional. When you receive such an object through this call, you never know for sure that XScriptProvider is supported (even if "in practice" you never had a case where it didn't), you must do the additional checks I listed in the last paragraph. Now you could say: well, then lets's change the documentation of loadComponentFromURL that it will return an object implementing css.document.ImprovedOfficeDocument where XScriptProvider is mandatory. But this would break compatibility: Let's assume there is a document type "FooDocument" that was implemented by a developer and integrated into Ooo by the usual Configuration files. The developer wanted that this document type could be loaded by loadComponentFromURL, so he made sure that his implementation supports css.document.OfficeDocument. A change in the specification of loadComponentFromURL would break his contract and so is not acceptable. Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
