[WebKit-devel] KDE WebKit status update [Remix]
Urs Wolfer
uwolfer at kde.org
Wed Oct 14 21:07:28 CEST 2009
On Tuesday 13 October 2009 19:17:50 Michael Howell wrote:
> On Tuesday 13 October 2009 09:21:56 Dawit A. wrote:
> > Not really... A cookie management application would have no use for the
> > AccessManager. The same if you want to integrate with the platform
> > specific cookie manager whenever possible (casuse the Qt version is
> > useless), but want to stick with QHttp.
>
> I see your point.
>
> > Well IMO if we want to really make the intent of these classes clear,
> > they should be put under a clear namespace, e.g. KDENetworkIntegration.
> >
> > namespace KIO
> > {
> >
> > namespace KDENetworkIntegration
> > {
> >
> > class AccessManager : public QNetworkAccessManager
> > {
> > ...
> > };
> >
> > class CookieJar : public QNetworkCookieJar
> > {
> > ...
> > };
> >
> > } // namespace KDENetworkIntegration
> >
> > // TODO: Remove KDE 5. BC
> > typedef KDENetworkIntegration::AccessManager AccessManager
> >
> > } // namespace KIO
> >
> > I rather prefer that nested namespace because the sole purpose of the
> > second namespace is to indicate the intent of these classes. It also
> > removes the classes out of the toplevel KIO namespace... Anyhow, I
> > really do not have any preference how this is handled so long as the
> > class is placed in the correct location in the end...
>
> That'd work pretty well. Of course, you'd need to do it in the opposite
> direction (typedef AccessManager KDENetworkIntegration::AccessManager) to
> maintain binary, as well as source, compatibility.
>
> I don't really have a preference how, I'd just like it to be clear that the
> classes go together.
>
Ok, I think this idea is also okay. One note I have written down before
already: The namespace should be KdeNetworkIntegration instead of
KDENetworkIntegration. See [1]. Another example in kdelibs is KAboutKdeDialog.
And yeah, for BC, you need to do the typedef as Michael suggested (IHMO).
Bye
urs
[1] http://techbase.kde.org/Policies/Library_Code_Policy#Naming_Conventions
More information about the WebKit-devel
mailing list