FS' API Incompatibility Wishlist
That's just my personal list of UNO APIs I would like to change incompatibly, if we are ever allowed to. Note there's much more than this. I just can't remember at the moment, but when working with API, I regularily encounter things which now will hopefully appear here over time.
setRowSetshould be allowed to throw a NoSupportException
- There should be an interface merging XRow and XResultSet. Both are nearly always used together, and having to work with two interfaces, one for navigating through the result set, and one for querying the actual values, sucks.
- XContent should have direct access to selected properties. Asking for a given property by executing a command named
getPropertyValues, which returns a
XResultSet, through which you need to navigate, is absolutely ridiculous.
- various XDatabaseMetaData methods should take
anys instead of strings. For instance, getTables should take an
anyfor the schemaPattern, where
NULLindicates "all schemas", as in JDBC.
- XPropertyContainer::addProperty should allow for
NULLdefaults, by separating between the type of a property, and its default.
- XSet should allow for for non-mutable implementations, by throwing a NoSupportException at the insert/remove method. For consistency reasons, this should then probably be extended to all container interfaces.
- XFilter::filter definitely needs to allow for more than a
RuntimeException. At least a
WrappedtTargetExceptionis mandatory here.
- DoubleInitializationException and AlreadyInitializedException save the same purpose, so they should be consolidated into one exception class. And of course this new class should not reside in module
frame, but in some generic module (
beans?). Probably, XInitialization::initialize should throw this exception then.
XInteractionHandler::handleshould return a boolean, which indicates whether the given request could be handled. This would allow clients to fall back to other means of user-notification. In the current form, you must know which exceptions are handled by the interaction handler, and this knowledge can be out of date over time. Alternatively, you can add a confirmation continuation to the request, and assume that if no continuation, not even this one, has been selected, then the handler couldn't handle the request - which is an error-prone heuristics, too.
- css.text.FontRelief and * css.awt.FontRelief should be consolidated
- XFilter::filter should be allowed to throw exceptions (
InsufficentArguments, or the like)
XStorable::storeand friends should allow for a
WrappedTargetException. This would allow implementations to wrap e.g. the
InteractiveAugmentedIOExceptionwhich can be thrown by usual UCB methods.