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

List:       kde-core-devel
Subject:    Re: KDE 3.0 - the last steps
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2002-03-22 14:54:12
[Download RAW message or body]

On Fri, Mar 22, 2002 at 03:07:15PM +0100, Rolf Magnus wrote:
> On Friday 22 March 2002 14:24, Simon Hausmann wrote:
> 
> > > item = addItem(group, "key", i18n("key"));
> > > setPrefix(item, "prefix");
> > > setSuffix(item, "suffix");
> >
> > Hm, that looks ugly compared to item->setPrefix IMHO.
> >
> > Is this attempt of preventing the developer from doing unlikely
> > stuff really worth it, at the cost of a non-OO API? :-}
> 
> Looks a bit ugly to me, too. But we didn't want public methods to set those 
> values, because only plugins are supposed to do so. So yes, basically you're 
> right. Carsten said that he thinks its better so, and we already did this 
> now. But you get the methods with only few parameters that you wanted, so you 
> should be at least partially happy with it ;)

;)

What if everthing would be value based? The application could do
what it wants with the information it retrieves from the framework,
while still allowing to use implicit sharing to keep memory usage
down.

(to get my API rants down to a point I should probably better make a
patch -- remind me on irc about it, tonight :)

> > Yes, that would be bad :) I think the difference here is that it
> > simply doesn't break binary compatibility, which was the cause for
> > the ramblings, not the package dependencies.
> 
> What's the difference? I mean BIC does also just result in package 
> dependancies, no?

Yes, but binary incompatibility affects more than the packages we
have control over (in the sense that they are part of a KDE release) .

So it comes down to the point that we have a different opinion on
installing header files containing notice like 'Do not use these
methods, they will change in 3.1' . I for one believe that this
shouldn't happen and that such header files should not get
installed. One the other hand one can argument that even Qt does
this (include/private/*) . I can't remember if this happened in
kdelibs in the past.


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