Can IDocumentationProvider::homePage be non-const?

[Milian Wolff]

On Tuesday, 1. December 2009 21:30:05 Milian Wolff wrote:
> On Monday, 30. November 2009 22:54:19 Milian Wolff wrote:
> > On Monday 30 November 2009 22:12:58 Andreas Pakulat wrote:
> > > On 30.11.09 18:53:51, Milian Wolff wrote:
> > > > On Monday, 30. November 2009 18:28:26 Andreas Pakulat wrote:
> > > > > On 30.11.09 17:14:23, Milian Wolff wrote:
> > > > > > Hey all, esp. Apol:
> > > > > >
> > > > > > Can I remove the "const" from IDocumentationProvider::homePage()
> > > > > > ? Thing is, that I want to pass "this" as parent/provider to the
> > > > > > returned IDocumentation. This fails, since this is const, but it
> > > > > > should be non-const.
> > > > >
> > > > > I strongly object to that. A getter like homePage ought to be
> > > > > const, else its suggesting to do something other than fetching some
> > > > > data.
> > > > >
> > > > > As David said, either use const-cast, or maybe you should fix the
> > > > > rest of the calling chain to also be const.
> > > >
> > > > Hm, ok but than I'd say other places have to become const as well:
> > > >
> > > > Provider:
> > > > - documentationForIndex (same problem with parent as above)
> > > > - documentationForDeclaration (again, same)
> > > > - indexModel (this one definitely, will change it asap)
> > >
> > > See below
> > >
> > > > - jumpedTo (since it only emits addHistory with a IDocumentation ptr)
> > >
> > > This one sounds more like a signal thats being emitted, IMHO its a bad
> > > name for anything else than that..
> >
> > It takes just an KUrl and emits addHistory(KSharedPtr<IDocumentation>),
> > so it's more than a simple signal (but very close to it).
> >
> > > > Documentation:
> > > > - provider() should return a const KDevelop::IDocumentationProvider*
> > > >
> > > > Should I do that? Imo having it all const I'd have no problems
> > > > what-so-ever and wouldn't require any const-casts. The provider stays
> > > > the same, the DocumentationController is the one that changes.
> > >
> > > Without any look at the api that makes sense to me from purely the
> > > function names. Of course you might start on a snowball here if the
> > > implementations for those functions also need some kind of non-const
> > > object...
> >
> > I'll have a look at it, and if it works out I'll change it accordingly.
> 
> OK, all done now. I think I constified pretty much everything in the API
>  and did not require any deep changes in the implementations. Nice!

Hm, one thing I forgot:
should the IDocumentationProvider returned by m_provider be const? I mean the 
public API only consists of const stuff, but I still have to const_cast<> it 
before I can return it...

And it looks like pointer to providers are used quite often in KDevplatform 
(the documentation controller esp.).

It would require lots of (simple) changes there, just to get rid of a single 
const_cast - is it worth it?

-- 
Milian Wolff
mail at milianw.de
http://milianw.de