The Sql.Sql object will however be created only once, while the wrapper acts for every call, so that trade off is easy. The question is however if we want the possibility to return different objects from create methods.
It would be possible to let Sql.pike/Sql.pmod inherit Sql.DB and add an optional `() that returns the actual objects. Also ugly, but doesn't require any language changes.
/ Martin Nilsson (DivX Networks)
Previous text:
2004-10-13 23:39: Subject: Re: MySQL big_query in 7.7
The only really new API here is big_typed_query and the streaming variants, but I think all the query variants except the basic query() function should follow the same API for consistency.
Still, it ought to be possible to do away with the Sql.Sql wrapper. That might need changes in some of the db specific implementations, but if there are compatibility issues with that they shouldn't be worse than that #pike compat goo is an acceptable solution.
There is a type problem if we try to remove the Sql.Sql wrapper, though: The base class for the db specific variants should be Sql.Sql to get the typing correct, but that means its create function would have to replace itself with a different object. An easy and fairly passable way to deal with that is to allow create() to return the object that should be the result of the clone operation. That's only ugly because it unnecessarily instantiates an Sql.Sql object solely to call create() in it. True static functions would be nice.
/ Martin Stjernholm, Roxen IS