KIO::Slave is inextensible!

[Waldo Bastian]

On Wednesday 05 February 2003 12:59, Leo Savernik wrote:
> Hello,
>
> In an attempt to create a highly optimized KIO::Slave for data urls that
> avoids the need to spawn an own kioslave process, I hit the following
> problems:
>
> 	KIO::Slave *KIO::Slave::createSlave(...)
> 	KIO::Slave *KIO::Slave::holdSlave(...)
>
> Those return a Slave and not a SlaveInterface, so I *must* derive from
> Slave at any rate, leading to another, really grave problem:
>
> 	KIO::Connection *KIO::Slave::connection() { return &slaveconn; }
>
> While SlaveInterface also defines this method and returns a pointer to some
> dynamically allocated Connection object, KIO::Slave::connection() returns
> an embedded object. That wouldn't be troublesome if this getter method
> weren't inline. So it's *impossible* to hook in an alternative Connection
> object for a Slave-derived class, but I need this badly.
>
> Possible solutions:
> - simplest solution: ditch KIO::Slave::connection() and let
> KIO::SlaveInterface::connection() do the work. However, it's BIC.

We could set m_pConnection and change KIO::Slave::connection() to return 
m_pConnection I think.

It's not that KIO::Slave::connection() is widely used outside kdelibs/kio

> If anybody knows better solutions please tell me. If this is too
> complicated for KDE 3 to implement, I opt for removal of the offending
> Slave::connection() method for KDE 4.

It's mostly used for calling send / resume / suspend I guess?

We could implement those as part of Slave (SlaveInterface?). 
That would give a much nicer interface if you want to derive from it. 
Unfortunately they would need to be virtual for that, so it's not too
usefull to do that before KDE 4.

It is posible to hack around it and then do a cleanup in KDE 4:
* Add a flag to Slave to indicate "to be used as baseclass".
* Add non-virtual send/resume/suspend functions that forward to connection()
  unless the object is used as baseclass. In that case they dispatch
  themselves via the virtual_hook().
* Remove the use of Slave::connection() throughout kdelibs/kio and call the
  above functions.
* Now you can derive from Slave an implement a virtual_hook() function
  that handles send/resume/suspend.
* In KDE4, make send/resume/suspend virtual.

This will not work too well with code that is using Slave::connection(), but
I doubt that that will cause much problems in practice.
(In theory an existing application might not be able to communicate with 
slaves that are derived from Slave this way then.)

Cheers,
Waldo
-- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com