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

List:       kde-core-devel
Subject:    Re: KTextEditor enhancement
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2001-10-08 9:22:19
[Download RAW message or body]

On Sun, Oct 07, 2001 at 11:12:56PM +0200, Christoph Cullmann wrote:
> - there should be a queryInterface (QString name) function to allow progs to \
> implement the interface even if they don't support all stuff and to allow other \
> progs to query what is supported (hehe, right, stolen the idea from mhk's KEditor \
> in gideon, but a bit other way of implementing it)

I think this isn't even necessary (anymore ;-) . You could aswell
use rtti (dynamic_cast) or qt_cast.

> - I don't like the idea of spliting the interfaces in 1000s of classes (like in the \
> keditor stuff in gideon, which is too big in my eyes), I think of something like \
> this: 
> i.e. for the KTextEditor::View class something like this
> 
> class View
> {
> virtual bool queryInterface (QString name) { return false; };
> 
> // this stuff is in editInterface
> virtual void insertLine () = 0;
> virtual void killLine () = 0;
> 
> // this is in undoInterface
> virtual void undo () = 0;
> virtual void redo () = 0;
> }
> 
> If queryInterface says true for "editInterface", the prog which uses the part knows \
> that the insert and kill stuff is implemented, if undoInterface is false for \
> example it knows, the current part doesn't implement the undo/redo stuff (the \
> virtual functions aren't reimplemented there).

Well, but you have to implement the pure virtual fuctions to
instantiate an object of that type. I fail to see how that is
supposed to work, other than providing default implementations,
which looks wrong to me, making the caller think there is support
for something that isn't really working or requires a previous
check. I find it more intuitive to ask an object if it implements a
certain interface by doing somthing like this:

UndoInterface *undo = dynamic_cast<UndoInterface *>( document );
if ( !undo )
    return; // ...

fooBar( undo->isRedoAvailable() );

connect( document, SIGNAL( undoStatusChanged( bool ) ),
         bleh, SLOT( bar() ) );

That gives you both in one: You ask a component for an interface.
Either you get a reference and then it's fully functional or you get
a null pointer and you know there's nothing to get there :)

In fact I like the idea of having only pure abstract interfaces and
a reference to a QObject * from which you can query those interfaces
(using dynamic_cast (or qt_cast ;-) .

That makes it easy on the implementation side (want to support an
intreface? just multiply inherit and do so) as well as on the client
side (consistent querying (dynamic_cast) , references to
functional interfaces while still having QObject signal/slot/property 
sugar and no library dependency at all (no libktexteditor.so/la) ) .

Just some thoughts.

Simon


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