[Mulgara-general] Mulgara API's

[Paul Gearon]

On Mon, Feb 25, 2008 at 6:01 PM, Alex Hall <alexhall at revelytix.com> wrote:
> Returning to an earlier topic...

<snip/>

>  It would be nice if the results from executing a Command could be
>  strongly typed somehow such that, if I know I'm executing a Query
>  command then I know at compile time that I have to get back an Answer
>  object rather than casting from Object.  Clearly this isn't a necessity
>  but it would be a convenience.  Do you see this as practical or feasible?

Already done (Friday).  :-)  I just haven't had a chance to check it in.

It's a natural consequence of calling back from the connection to the
command.  All commands have to return the same thing (and Object)
since that is their interface, but the Connection can have multiple
methods.... one for each type of command.  Of course, most commands
can go through the same method, but you can override the parameter
types for commands like Query so that it returns an Answer instead of
the usual Object.  (Actually, with few exceptions, they all return
strings).

Of course, by using overloaded methods like this, you get static
binding, which is fine when you are writing code to run commands.
e.g. You have several methods that look like:
  String Connection.execute(Command cmd);
  Answer Connection.execute(Query query);

These are easily differentiated by the parameter types, but the
differentiation is done at compile time.  If you need to differentiate
at runtime you need to use polymorphism.  This is the case when using
a parser to convert a string into a command that you want to execute,
since it is only once you have parsed the string that you know what
kind of command you will have.  This is one of the reasons why
execute(Connection) is defined on Command:
  Object Command.execute(Connection conn);

(The other reason is so that functionality for each command can be
implemented in that command class definition.)

Paul