Namespaces in libkdecore

[Holger Freyther]

On Saturday 01 May 2004 20:49, Matthias Ettrich wrote:
> On Saturday 01 May 2004 20:29, Holger Freyther wrote:
> > On Saturday 01 May 2004 20:08, Matthias Ettrich wrote:
> > >Now that the K prefix
> > > is reserved for KDE and new versions of the libraries are released
> > > together, where is the benefit?
> >
> > clean namespaces, clean versioning...
>
> Nothing is clean if we assume that people use 'using' anyway. With regards
> to versioning: think about how you would really make use of this. Take
> libraries into account, the fact that ELF already has a version number
> associated with a shared object file, source and binary compatibility and
> code with 'using' directives. Also take readability into account. Even if
> the namespace is only KDE, KDE::LineEdit is a lot harder to work with than
> KLineEdit (and it makes the code look ugly).
>
> Forcing people to add 'using' in every cpp-file, and KDE::FOO::BAR to every
> headerfile is a rather big change, it shouldn't be done without good
> reasons and use-cases that describe how we would benefit from the change in
> the future. "cleaner" is a weak argument for putting additional burden on
> application developers, whereas "easier" would be a strong argument. Having
> said this, "..." is a rather unspecific argument, so I don't know whether
> it's strong or weak :)

Maybe C++ is just deprecated even if we all love it and can do awesome things 
like MetaProgramming with it and the following is slighlty Off topic and just 
some randoms thoughts as namespaces really don't make it easier to write a 
brand new application.


Let me switch Technology and mention Qtopia. There you've the problems that 
newer compilers support newer CPUs ( gcc2 vs gcc3 on XScale ) or introducing 
a new platform API but you still need to support the 'older' platform. So one 
could create bundles of classes and cleanly mangle the names (using 
namespaces) and compiler version inside that bundle. So internally stuff like 
the QPEApplication could be the same or use same functions between different 
versions and compilers ( extern "C" or such to stick with current 
technology ). This way different major and minor releases could integrate 
with each other. So ideally one even would be able to mix gcc2,gcc3 code if 
someone wants it. At least with such technology one could extend the lifetime 
of a platform without beeing unable to go with current technology or new 
major releases.

That is just a thought and using a namespace would only be one part of the 
solution and if applyable at all is just a different question. But with a 
cleaner seperation of KDECORE,UI,KIO one could also allow easier integration 
with restricted environments. So a special dynamic loader would be able to 
see which namespaces a special application is allowed to pull in into its 
virtual space.
For example on a phone you don't want to give an untrusted application access 
to the GSM internals. You would put this application in a 'class' where it 
wouldn't be allowed to use these kind of symbols... But again this might not 
be desirable and might not apply to what KDE evolves to.

On a different note I wonder how practiacle the whole thing is as libtool got 
issues with versioning of libraries, no app bundles with sections exist and I 
don't know if a elf can hold both gcc2 and gcc3 mangled code and whatever 
needs to be patched to actually to load the right part. 
Then there is also the trend to go away from bundles and have smaller 
libraries as every QObject also adds static data to the library.

So for now I don't see how namespaces would ease development. Besides for 
better seperating the classes from each other Core, GUI, Services, IO.

so just some brainstorming I hope you forgive.

-- 
_____________________________________________
Holger 'zecke' Freyther
Project OPIE- the Open Palmtop Integrated Environment
http://opie.handhelds.org 
Sponsor me! Donate Hardware!
http://handhelds.org/~zecke