That's surely important, but since that code seem to me quite complex I was wondering if it was the next block to optimize.
That said, I absolutely can not waste time... If you already know there is no better way to make that work done, I will go for other place to look. I've already saw that, given that design, the code is as efficient as it can be. But since that they are heavyly used types (and since the Format() method signature is so similar to the String one), I was wondering if we could optimize it by making it faster. May be, by redesign it, if the advantage is big enougth. What do you think about that? I'm completely misleading? Giacomo On Tue, Mar 10, 2009 at 6:30 PM, Pascal Craponne <[email protected]> wrote: > I wrote those classes, and their main purpose was to handle databases like > Ingres that don't support named parameters. With these classes parameters > can be identified and ordered to provide correct SQL statements. Until > someone finds a more efficient solution, I suggest to keep them :) > > Pascal. > > jabber/gtalk: [email protected] > msn: [email protected] > > > > > On Tue, Mar 10, 2009 at 17:56, Giacomo Tesio <[email protected]> wrote: > >> It seem to me that by using plain strings instead of those classes would >> be more efficent. >> >> But may be I'm missing something, so before starting a refactoring which >> could be really complex and had great impact on the existing code, I'd like >> to know why it's has been designed so. >> >> Can anyone explain me what I'm missing? >> >> >> Giacomo >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
