On Wed, 2006-10-18 at 09:10 +0200, Michael Van Canneyt wrote: > > On Tue, 17 Oct 2006, Joost van der Sluis wrote: > > > On Fri, 2006-10-06 at 07:51 +0200, Martin Schreiber wrote: > > > On Thursday 05 October 2006 22.41, Joost van der Sluis wrote: > > > > > > Now I'm thinking about using an interface, to avoid double code. > > > > > > But I > > > > > > don't know what effect that has on run-time performance. I mean, the > > > > > > idea was to make if faster ... > > > > > > > > > > A very good idea! It can then be implemented by a common worker class. > > > > > TSQLConnection and TSQLTransaction should be independent of TSQLQuery > > > > > and > > > > > TSQLQuery should get its own unit. > > > > > > > > Can you explain to me how I should construct this worker-class? As > > > > Michael said, my solution won't work... > > > > > > > If TSQLConnection or TSQLTransaction need callbacks into TSQLQuery and > > > "TSQLQueryUni" do it by an corba interface (at the first glance I didn't > > > see > > > any). > > > To implement the common functions of TSQLQuery and TSQLQueryUni use a > > > "worker > > > class" which does callbacks by an corba interface. > > > > Ok, I tried to implement this. I still don't understand why I should > > need an interface for this, though. > > You don't need an interface ? What good would that do you ?
No idea. It was Martin's suggestion. > > Attached is a patch that does this. It's work in progress, TSQLQuery > > doesn't work with this patch, but the TSQLUnidirectionalQuery does. At > > least, a basic select works... > > > > But I wanted to make things faster. I'm not feeling comfortable with > > creating more wrapper-class layers, more complexity, for nothing, if it > > doesn't result in any speedup. > > Why would it work faster ? The only thing a unidirectionalquery query gives > you is less memory requirements, because it needs only 2 buffers. Less copying around of the buffers. But I did some tests, it's negligible. I don't see any advantage in this worker-class, or the unidirectional query anymore. Maybe that Martin still sees some advantages? Joost _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
