Can IDocumentationProvider::homePage be non-const?

[Aleix Pol]

What I do in Qt doc is to have a static member with the provider and return
that one.
That way every IDocumentation instance doesn't store a pointer to the
provider (which is shared, of course).

On Tue, Dec 1, 2009 at 9:39 PM, Milian Wolff <mail at milianw.de> wrote:

> 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
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20091201/9cf4f875/attachment.html>