Can IDocumentationProvider::homePage be non-const?

[Milian Wolff]

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!

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