Difference between revisions of "User:Frank Schönheit/Changing API incompatibly"
From Apache OpenOffice Wiki
(→various) |
(→various) |
||
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 | + | * [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/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.html::initialize] should throw this exception then. | * [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.html::initialize] should throw this exception then. | ||
− | |||
=== 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) |
Revision as of 07:28, 19 March 2009
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 aXRow
/XResultSet
, through which you need to navigate, is absolutely ridiculous. - various XDatabaseMetaData methods should take
any
s instead of strings. For instance, getTables should take anany
for the schemaPattern, whereNULL
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 aWrappedtTargetException
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
orframe
, but in some generic module (util
?lang
?beans
?). Probably, XInitialization.html::initialize should throw this exception then.
Exception declarations
- XFilter::filter should be allowed to throw exceptions (
InvalidArgument
,InsufficentArguments
, or the like)