[Mulgara-general] Mulgara API's

[Alex Hall]

Returning to an earlier topic...

Paul Gearon wrote:
<snip>
>>> cmd = interpreter.parse("select $x from <rmi://hostname/server1#data>
>>> where $x $y $z;");
>>> Answer answer = (Answer)cmd.execute(conn);
>>>
>>>
>>> You can also manually create Commands if you want to do that instead
>>> of using iTQL:
>>>
>>> new SetAutoCommit(false).execute(conn);
>>> new Load(fileUri, modelUri, false).execute(conn);
>>> Command c = new Commit();
>>> c.execute(conn);
>>> new Load(fileUri2, modelUri, false).execute(conn);
>>> c.execute(conn);
>>>
>>>
>>> Yes, this looks a little backwards (Ronald pointed out that it should
>>> look like connection.execute(command)).  I'll have to look at this,
>>> but for the moment it works.
>>>
>> Creating commands manually is probably the method I would prefer, if  
>> the
>> alternative is building up an ITQL string and then sending it back
>> through the parser.  You're right, this calling convention feels  
>> pretty
>> awkward.  If I decide to go down this route, I would certainly be
>> willing to take a look at refactoring that code.
> 
> Actually, it's just a matter of changing it to a visitor pattern.   
> Connections just need to implement an execute method for every Command  
> type, with the form:
> 
> Object execute(CommandImplementation cmd) { return cmd.execute(this); }
> 
> This is standard boilerplate visitor pattern stuff, and one of the  
> reasons I hate Java.  :-)
> 
> It would only take 10 minutes to do.  Maybe I'll do it in the morning.
> 
> (yes, these methods can be avoided by putting all the functionality in  
> a Connection class, avoiding the callback, but this does not use  
> encapsulation or information hiding, and makes for a monolithic class,  
> which is always a bad idea.)

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?

Regards,
Alex