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

List:       kde-core-devel
Subject:    Re: KIO vs. kioErrorString
From:       Dawit Alemayehu <adawit () earthlink ! net>
Date:       1999-11-30 16:21:56
[Download RAW message or body]

On Tue, 30 Nov 1999, Richard Moore wrote:
> Dawit Alemayehu wrote:
> > 
> > On Mon, 29 Nov 1999, Matt Koss wrote:
> > > I get this warning when trying to use kioErrorString in file slave :
> > >
> > > file.cc:    type `KIO' is ambiguous baseclass of `FileProtocol'
> > > make: *** [file.o] Error 1
> > >
> > > FileProtocol inherits KIO, that's why I am confused.
> > > Doesn't matter what I include or whether I call KIO::kioErrorString( .. )
> > >
> > > Anybody has a clue ?
> > 
> > I do.  This is caused by double inheritance in KIOProtocol, the parent class of
> > FileProtocol.  This is because the parent classes of KIOProtocol, KIOConnectionSignals
> > and KIOConnectionSlots both inherit from KIO.  Hence, the compiler does not know
> > which kioErrorString(...) to call.
> > 
> > The quick (short term) fix without break anything is to make KIOProtocol
> > inherit KIO as well and remove the inheritances from KIOConnectionSignal and
> > KIOConnectionSlot in kio_interface.h.  This means all references to KIO's
> > constants in KIOConnectionSignal and KIOConnectionSlot have to be qualified.
> > In the long run, all the io-slaves have to be modified so that they respect
> > the KIO namespace, i.e. they refer to all the variables and methods as
> > KIO::blabla.   Then the inheritance can be removed from KIOProtocol.
> 
> Why don't we merge KIOConnectionSignal and KIOConnectionSlot instead?

I also have thought about this.  I did not know why these two classes were
separated to begin with in the first place ; so I did not touch it.  And
in fact a little greping shows that there is nothing, at least in kdelibs and
kioslaves that inherits each of these classes individually.  So it is possible
to do this.  BTW,  I already commited the quick fix I mentioned above, but it
should not be hard to change it back if needed.

> There is no problem inheriting the namespace class (look at the Qt
> class for example). I don't see why you want to remove the inheritence
> completely.

Hmmm... I guess it is a matter of style.  For me, creating a class for the sake
of namespace means that class should not be inheritable at all.  Infact this is
what I like about the "final" keyword in Java.  No inheritance.  However, there
is nothing wrong with inheriting such classes except that you will probably run
into this double inheritance issues from time to time.

Regards,
Dawit A.

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