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

List:       ktexteditor-devel
Subject:    Re: KTextEditor container extension
From:       Joseph Wenninger <jowenn () kde ! org>
Date:       2007-08-01 9:08:52
Message-ID: 200708011108.52905.jowenn () kde ! org
[Download RAW message or body]

Hi!

On Monday 30 July 2007 22:33, Philippe Fremy wrote:
> Christoph Cullmann wrote:
[...]
> >
> > Hmm, but why? If a editor implements this interface, it should just
> > support all methods. As there are << 10 methods, I don't see any use in
> > the supports* methods beside uglifying the API, or?
>
> I made it flexible to the extreme but that may not be indeed the right
> way (tm).

You don't have to over engineer the inteface.
*)If an interface contains completely unrelated functionality it should be 
split up into two or more, otherwise all function should always be 
implemented. 
*)For future BC extension of extensions you would just create another 
interface.

> How do you see it ? If an editor returns something different that NULL
> on qobject_cast<ContainerExtension>( Editor::containerExtension() ),
> then the whole interface should be supported ?
>

Yes

> That would make it simpler indeed. And now that I think of it, that's
> the way KTE currently supports extensions.

It's easier for implementors and for users. In theory the KTE interfaces are 
ment to be easily usable.

Kind regards
Joseph Wenninger

-- 
"People's characters are strengthened through struggle against
difficulties; they are weakened by comfort." (Old Chinese adage)


_______________________________________________
KTextEditor-Devel mailing list
KTextEditor-Devel@kde.org
https://mail.kde.org/mailman/listinfo/ktexteditor-devel
[prev in list] [next in list] [prev in thread] [next in thread]