Difference between revisions of "User:Frank Schönheit/Changing API incompatibly"

From Apache OpenOffice Wiki
Jump to: navigation, search
(various)
(various)
 
(20 intermediate revisions by 2 users not shown)
Line 8: Line 8:
 
* various  [http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XDatabaseMetaData.html XDatabaseMetaData] methods should take <code>any</code>s instead of strings. For instance, getTables should take an <code>any</code> for the schemaPattern, where <code>NULL</code> indicates "all schemas", as in JDBC.
 
* various  [http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XDatabaseMetaData.html XDatabaseMetaData] methods should take <code>any</code>s instead of strings. For instance, getTables should take an <code>any</code> for the schemaPattern, where <code>NULL</code> indicates "all schemas", as in JDBC.
 
* [http://api.openoffice.org/docs/common/ref/com/sun/star/beans/XPropertyContainer.html#addProperty XPropertyContainer::addProperty] should allow for <code>NULL</code> defaults, by separating between the type of a property, and its default.
 
* [http://api.openoffice.org/docs/common/ref/com/sun/star/beans/XPropertyContainer.html#addProperty XPropertyContainer::addProperty] should allow for <code>NULL</code> defaults, by separating between the type of a property, and its default.
 +
* [http://api.openoffice.org/docs/common/ref/com/sun/star/container/XSet.html 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.
 +
* [http://api.openoffice.org/docs/common/ref/com/sun/star/document/XFilter.html#filter XFilter::filter] definitely needs to allow for more than a <code>RuntimeException</code>. At least a <code>WrappedtTargetException</code> is mandatory here.
 +
* [http://api.openoffice.org/docs/common/ref/com/sun/star/frame/DoubleInitializationException.html DoubleInitializationException] and [http://api.openoffice.org/docs/common/ref/com/sun/star/frame/AlreadyInitializedException.html 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 <code>ucb</code> or <code>frame</code>, but in some generic module (<code>util</code>? <code>lang</code>? <code>beans</code>?). Probably, [http://api.openoffice.org/docs/common/ref/com/sun/star/lang/XInitialization.html#initialize XInitialization::initialize] should throw this exception then.
 +
* <code>XInteractionHandler::handle</code> should 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.
 +
: See [http://api.openoffice.org/docs/common/ref/com/sun/star/task/XInteractionHandler2.html css.task.XInteractionHandler2].  Apart from that, the original design decision was that an interaction handler has handled a request if it has selected one of the passed-in continuations (which cannot be observed by code that does not control the continuations, so cannot observe whether any of them has been selected&mdash;which, IIRC, was the reason to come up with <code>XInteractionHandler2</code>).  [[User:Sb|Sb]] 14:02, 28 May 2010 (UTC)
 +
* [http://api.openoffice.org/docs/common/ref/com/sun/star/text/FontRelief.html css.text.FontRelief] and [http://api.openoffice.org/docs/common/ref/com/sun/star/awt/FontRelief.html css.awt.FontRelief] should be consolidated
 +
* [http://api.openoffice.org/docs/common/ref/com/sun/star/form/XDatabaseParameterBroadcaster2.html XDatabaseParameterBroadcaster2] should replace [http://api.openoffice.org/docs/common/ref/com/sun/star/form/XDatabaseParameterBroadcaster.html XDatabaseParameterBroadcaster]
 +
* [http://api.openoffice.org/docs/common/ref/com/sun/star/sdbcx/XColumnsSupplier.html#getColumns XColumnsSupplier.html::getColumns] should be allowed to raise an <code>SQLException</code>
 +
* XDialogProvider::createDialog(*) and XContainerWindowProvider::createContainerWindow should be allowed to throw a WrappedTargetException
 +
* XMessageBoxFactory::createMessageBox should be allowed to throw non-RuntimeExceptions. At the moment, if you try to create windows which require a ParentWindow, but don't pass a parent, the method silently returns NULL. Sounds weird to me.
 +
* XDialog2::setHelpId should be removed - help IDs are dead, help URLs are the way to go
 +
* merge XFilePicker/XFilePicker2
  
 
=== Exception declarations ===  
 
=== Exception declarations ===  
  
 
* [http://api.openoffice.org/docs/common/ref/com/sun/star/document/XFilter.html#filter XFilter::filter] should be allowed to throw exceptions (<code>InvalidArgument</code>, <code>InsufficentArguments</code>, or the like)
 
* [http://api.openoffice.org/docs/common/ref/com/sun/star/document/XFilter.html#filter XFilter::filter] should be allowed to throw exceptions (<code>InvalidArgument</code>, <code>InsufficentArguments</code>, or the like)
 +
* <code>XStorable::store</code> and friends should allow for a <code>WrappedTargetException</code>. This would allow implementations to wrap e.g. the <code>InteractiveAugmentedIOException</code> which can be thrown by usual UCB methods.

Latest revision as of 11:48, 1 December 2010

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.

various

  • XRowSetSupplier: setRowSet should 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 XRow/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 any for the schemaPattern, where NULL indicates "all schemas", as in JDBC.
  • XPropertyContainer::addProperty should allow for NULL defaults, 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 WrappedtTargetException is 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 ucb or frame, but in some generic module (util? lang? beans?). Probably, XInitialization::initialize should throw this exception then.
  • XInteractionHandler::handle should 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.
See css.task.XInteractionHandler2. Apart from that, the original design decision was that an interaction handler has handled a request if it has selected one of the passed-in continuations (which cannot be observed by code that does not control the continuations, so cannot observe whether any of them has been selected—which, IIRC, was the reason to come up with XInteractionHandler2). Sb 14:02, 28 May 2010 (UTC)
  • css.text.FontRelief and css.awt.FontRelief should be consolidated
  • XDatabaseParameterBroadcaster2 should replace XDatabaseParameterBroadcaster
  • XColumnsSupplier.html::getColumns should be allowed to raise an SQLException
  • XDialogProvider::createDialog(*) and XContainerWindowProvider::createContainerWindow should be allowed to throw a WrappedTargetException
  • XMessageBoxFactory::createMessageBox should be allowed to throw non-RuntimeExceptions. At the moment, if you try to create windows which require a ParentWindow, but don't pass a parent, the method silently returns NULL. Sounds weird to me.
  • XDialog2::setHelpId should be removed - help IDs are dead, help URLs are the way to go
  • merge XFilePicker/XFilePicker2

Exception declarations

  • XFilter::filter should be allowed to throw exceptions (InvalidArgument, InsufficentArguments, or the like)
  • XStorable::store and friends should allow for a WrappedTargetException. This would allow implementations to wrap e.g. the InteractiveAugmentedIOException which can be thrown by usual UCB methods.
Personal tools