Automatic color chooser

Andreas Pakulat apaku at gmx.de
Sun Aug 9 10:42:03 UTC 2009


On 09.08.09 12:33:05, David Nolden wrote:
> Am Sonntag 09 August 2009 12:10:31 schrieb Andreas Pakulat:
> > > Creating a library for 100 LOCs is overkill, makes maintainment more
> > > complicated rather than easier,
> >
> >
> > Thats wrong, any code thats shared via copy+paste is less matinainable then
> > code shared via a library or maybe just inline in a header file. Obviously
> > with copy+paste a fix/change in one copy will seldomly move over to all
> > other copies.
> But this is very simple and well working code. When moving it into a shared 
> place, a following fix/change in the library may break 10 places where the fix 
> was not tested properly. This makes maintainment much more complicated, as you 
> cannot change the code the way you like, and have to always be frightened that 
> someone else breaks the carpet you're standing on. It's essentially the 
> typical KDE madness we're seeing all day. ;-)

Well, thats a problem with _any_ shared library. Hence its important to
properly define the API and document it, such that users of the API can
know all the possible side-effects, undefined behaviours etc. 

> > > and reduces flexibility to a minimum by introducing one more API layer in
> > > between.
> >
> > Usually reduced flexibility shows that the API isn't used in enough places
> > and not mature enough. You can create a flexible API also in a shared
> > library.
> 
> Yes sure, but the API may become bigger then the actual code it is hiding. So 
> from an economical point of view, considering the work you have to put into 
> such a clean API, it may well not be worth it.

Ok, I guess I should've looked at the code in question in the first place.
Basically yes you're right, until the day when you really need to change
all places where the code has been copied to (because of a serious bug) ;)

Andreas 

-- 
If you think last Tuesday was a drag, wait till you see what happens tomorrow!




More information about the KDevelop-devel mailing list