[Mulgara-general] Mulgara API's

[Life is hard, and then you die]

On Mon, Feb 25, 2008 at 08:27:55PM -0600, Paul Gearon wrote:
> 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);

Another option is to use generics, something along the lines of

  public interface Command<T> {
     public T execute(Connection conn)
  }

  public class Query implements Command<Answer> {
      public Answer execute(Connection conn) ...
  }

  public interface Connection {
      public <T> T execute(Command<T> cmd)
  }

This avoid the multiple execute() variants, and works better if the
code uses something like

   Comand cmd = ...
   ...
   Object res = con.execute(cmd)

as it doesn't have to try and coerce a String to an Answer or
something.


  Cheers,

  Ronald