Hi Éric, > [copy'n'paste] > One of the problems here is modularity. When you write KDE driver,
Ah, this was in no way directed to the KDE driver. Sharing across components is more difficult, admittedly. And the fact that the driver implementation architecture has space for improvements is what started this discussion, so I won't harp on about this :) But just yesterday, I refactored some clases implementing control peers where 3 classes, all derived from the same base, completely duplicated code to handle some image displaying - where deriving (sic!) from one intermediate base class was sufficient to save quite some lines of code. That's more the "lazy" code duplication I mean: See how other implementations handle it, and copy'n'paste it into the own implementation, without even thinking about ways to share the code. > you don't > want to put your code in common with evolution's driver because evolution is > not under your responsability. Even if you did the effort, you would not be > sure that the evolution guys would appreciate: what if you introduce new > bugs? Well, why not? Sure, touching existing, working code needs at least verification later, and perhaps asking the owner. But see it the other way round: What if the code in the evolution driver contains a hidden bug, which you silently copy? Now when a year or so later this bug is discovered and fixed, nobody will remember you duplicated the code - chances are good *your* bug is not fixed. With this in mind, I'd strive to share any non-trivial amount of code, where possible. (As said, our drivers are, in some parts, not really a good example for code sharing. Though, over time, this improved - there's already a lot common stuff in the dbtools library. This includes things which at a first glance sound highly specialized, for instance the TSkipDeletedSet: Its code was originally used to skip deleted records in a dBase result set, since in dBase, the records are present in the file, but marked as deleted only. Surprisingly, some time later it rose that some ODBC drivers exibit a behaviour which requires exactly the same: skip deleted records provided by the backend, instead of forwarding them to the UI.) >>>Because you usually reuse things way too strong for your needs. >> >>Which I don't cosider bad. As long as there are other clients using the >>strength, and it doesn't cost extra in the implementation, that's okay >>to me ... > > Hmmm. Yes. No. Don't know. I still prefer code that uses only the necessary > minimalistic stuff. But that's perharps more an esthetical preoccupation than > a rational one, yes... Which is okay, too :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
