[ZOOM] Re: Java Binding - interface based (and some more
ajk at mds.rmit.edu.au
Fri Feb 13 00:59:51 CET 2004
On Thu, Feb 12, 2004 at 10:18:18AM +0000, Mike Taylor wrote:
> > So if you swap your underlying ZOOM implementation with another one,
> > your client code may start throwing exceptions as it may support
> > different optional bits. This may be acceptable, just pointing it
> > out.
> I think this is not merely acceptable but inevitable. It is a given
> that some implementations will support options that others don't.
> What are the alternatives for the latter implementations when called
> by an application that tries to use such an option? It can't succeed
> so the only question is _how_ it wants to fail: quietly or noisily. I
> think we've all had enough experience of quietly failing software to
> prefer the latter!
This is not necessarily true. Many of the options are hints as to
how the API should behave. Eg: how many records to get per present
request could be completely ignored by the API, and nothing will
change from the view of the programmer using ResultSet. Changing
elementSetName will of course make a difference.
But I will accept reality here. There will be some options that an
application may use (in general) that if you switch implementations
will no longer work. So (in general) the benefit of ZOOM is more
that it has a consistent and simple programming model. Lets face it,
people would not switch ZOOM APIs very often!
> > > > [the Query construction function] would take two strings: the
> > > > first is the query type, the second the query text.
> > >
> > > Ugh, a string query-type? Surely in a polymorphism-friendly
> > > language such as Java, different types of query should be
> > > represented by subclasses of Query? (That's what the C++ binding
> > > does.)
Ok, you win. I agree.
or similar, and they can throw an exception if that form of query is
not supported by an implementation. An implementation can also define
additional functions if it wishes.
More information about the ZOOM