[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    any more pros for nana?
From:       Stephan Kulow <coolo () kde ! org>
Date:       2000-01-25 20:52:58
[Download RAW message or body]

Hi!

It turned out that the import of nana into kdelibs
caused more problems than good. If I understand
correctly there are very few features we can use
and macros like A, I, L and the almost not existant
comments in the headers doesn't make it better.

kdebug improved dramaticly since we discussed first
time and "for all asserts" is not really what we
need, do we? And my personal experience showed that
the average KDE developer isn't ready for programming
by contract. You can write into the headers what you
want and put an assert if the constraints aren't full
filled, people will mail you to that the class is broken
and say "ah, thought I mail you before I read docs".

Sure, it's nice to block the user from doing what he
shouldn't do, but I see nothing kDebugError couldn't
handle. I prefer selfexplaining code over 
A(LG, whatever...) - really I do.

So - I would like to ask if there are any more users
of nana than Mirko and his kab within KDE that would
justify letting it in kdelibs? kab used nana quite
long before conditionally and I don't see a reason
why it can't do in the future. gcc users get ugly
warnings and non-gcc developers don't get anything.

I'm sorry for the work that Mirko put into integrating
it and Phil to fullfill our constrains, but I see no
reason to confuse developers by having two debug solutions
and kdebug is surely the one that fits better into the
KDE framework.

Opinions? I'd like to have this sorted out (possibly
removed) before the next release.

Greetings, Stephan

-- 
It said Windows 95 or better, so in theory Linux should run it
                                                GeorgeH on /.

[prev in list] [next in list] [prev in thread] [next in thread]