[ZOOM] Re: Java Binding - interface based (and some more
mike at indexdata.com
Thu Feb 12 11:18:18 CET 2004
> Date: Wed, 11 Feb 2004 12:39:01 +1100
> From: Alan Kent <ajk at mds.rmit.edu.au>
> > To clarify: it was not the intention of the AAPI to make a
> > distinction between "Illegal" and "unsupported" options. THey
> > both mean the same.
> > <snip>
> > the intent is:
> > setOption("supported-option", "value"); // OK
> > setOption("unsupported-option", "value"); // exception
> > setOption("X-anything", "value"); // OK but may be a no-op
> 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
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!
> The "best" Java practice is to have set/get functions (as per other
> long discussions I wont repeat here). A goal I have of the Java
> binding is to define a standard set of abstract classes and
> interfaces so client code can use different APIs with the only
> change being which class to start from. (This is not mandatory, but
> very nice to achieve.)
Yes, this is a very desirable goal.
> Matthew achieved this in his API by the caller supplying the
> ConnectionFactory the name of the Java class to use. Eg:
> This is the only line of code that should need to change to pick a
> different ZOOM implementation.
Yes. I believe this is the standard approach to choosing, for
example, what Saxon-compliant XML parser to use in a Java app.
> A side effect of this is the Java interfaces defined have to define
> all of the methods used by any implementation.
Yes -- if you use separate get/setters for each option.
> Is this a problem in practice? Probably not. How many ZOOM
> implementations will there be?
I would prefer not to allow our design decisions to be clouded by
expectations along these lines if we can avoid it, though. I'm sure
it never crossed Dennis Ritchie's mind that there would be more than
two or three C compilers!
> You can always cast down to a subclass to define additional
> implementation specific options.
> I can see the logic to say a query is independent of a Connection
> object. My issue was simply that in Matthew's API, the
> ConnectionFactory class is a real class, not a base class that an
> implementation redefines. This means it may be necessary to
> register both the class to use for creating Connection objects (as
> above) and Query objects. Maybe it would be better to instead
> register a single factory class (not the Connection class
> directly). Does this make sense Matthew?
[I am not Matthew :-) But to me it does.]
> I will let Matthew try and pick good class and interface names.
> A ZoomFactory interface (it does connections and query objects),
> and a ... ummm ZoomFactoryFactory class?
for more on this tendency :-)
> > > [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.)
> 'Query' is an interface - you do not call a constructor directly.
> It is likely that an implementation would have multiple subclasses.
> You need to call a createQueryObject() method to construct an
> implementation of the Query interface. This method needs to be
> supplied by each implementation (as the Query internals may be
> different), but you want a single standard way of creating the
> objects. Hence, 'type' and 'query'.
OK. But why a single
createQueryObject(String type, String source);
method rather than multiple explicit
methods? The irony here is of course that in this discussion, you and
I find ourselves advocating the opposite positions from those we hold
in the how-to-get-and-set-options argument!
> [Actually, I got these two arguments from the V1.4 abstract API.
> Type is an enumeration in the spec, but to keep it extensible I was
> proposing to use strings - also since Java does not have
> enumerations. But I am sure Mike does not disagree with his own
> spec! ;-]
You must NEVER assume that! :-)
Again, that approach to representing the spirit of the AAPI makes more
sense in some languages than others; I'd have thought that Java
culture would be more oriented towards the createPrefixQueryObject()
approach, but ... Well, what do I know?
/o ) \/ Mike Taylor <mike at indexdata.com> http://www.miketaylor.org.uk
)_v__/\ "One observed fact is worth any amount of expert opinion"
-- J. B. Hatcher, O. C. Marsh and R. S. Lull, 1907.
Listen to my wife's new CD of kids' music, _Child's Play_, at
More information about the ZOOM