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

List:       kde-core-devel
Subject:    Re: KIO vs. kioErrorString
From:       Richard Moore <rich () ipso-facto ! freeserve ! co ! uk>
Date:       1999-11-30 16:59:31
[Download RAW message or body]



Dawit Alemayehu wrote:
> 
> 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

This is the same reason that I didn't change it when I cleaned up the
KIO namespace. :-)

I think unless there is any disagreement we should fix this rather than
working around it. How would you feel about doing this before Krash
Waldo?

> 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

I agree - in fact I think I added a comment to this effect to the readme.

> 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.

I don't agree, but I can see where you're coming from. The double
inheritance problem is more due to the multiple inheritence of the
signals/slots classes than due to the KIO class.

Rich.


> 
> Regards,
> Dawit A.

-- 
     Richard Moore		rich@ipso-facto.freeserve.co.uk
http://www.robocast.com/	richard@robocast.com
http://developer.kde.org/	rich@kde.org

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