Tim Jansen's Blog (deutsch) |
2003/10/23
KDE 4.0
Auf kdedevelopers.net habe ich ein Plädoyer für eine KDE-basierte Server-Plattform geschrieben. Bei der Implementierung ist das Abhängigkeitsspiel soweit gegangen, bis ich KDE::OS::FD, eine Abstraktion für POSIX File Deskriptoren, geschrieben habe. Seitdem habe ich die zuvor erwähnten InputStream und OutputStream geschrieben, dann FdInputStream und FdOutputStream um auf KDE::OS::FD zuzugreifen, und KDE::OS::Console für Kommanozeilen Applikationen. Und darauf basierend das KDE::Test Framework, das nun vollständig ist. Nächste Schritte sind Java-ähnliche Buffered*Stream und ByteArray*Stream Implementationen. 2003/10/18
Exceptions
In den letzten Tagen gab es eine kleine Blog-Diskussion zwischen Joel Spolsky und Ned Batchelder um den Sinn und Zweck von Exceptions, und im Verlauf hat Ned Batchelder zwei interessante kleine Artikel hier und hier geschrieben. Ich fühle mich bestätigt :) 2003/10/13
KDE 4.0
Irgendwie finde ich mit jeder Funktion, die ich implementieren will, 2 weitere Funktionen, die ich dafür bräuchte und die mir auch fehlen. So geschehen am Wochenende. Die Klasse für XML Typkonversionen war fast fertig als mir bewusst wurde, dass ich kein Framework für Unit-Tests habe. Da ich es auch für die anderen APIs oft brauchen werde macht es Sinn, sowas im Framework zu haben. Also schaute ich mich ein wenig um, und es gab eigentlich nur cppunit und qtunit. cppunit hat das ursprünglich simple JUnit unglaublich aufgebläht und verkompliziert, das allerdings gut dokumentiert und unter LGPL. qtunit ist komplett undokumentiert, GPL und trotz des Namens nicht sehr Qt-haft, was sich vor allem in den STL-basierten Exceptions zeigt. Um es kurz zu machen, ich habe mal wieder angefangen, mein eigenes zu schreiben. Mit einer API nah an JUnit, aber noch simpler. Zudem werde ich QObject Slots benutzen, womit das Schreiben von Test ähnlich einfach wie in Java wird. Namespace ist KDE::Test. Ich habe mich für Exceptions entschieden, allerdings nur auf einer pro-Namespace Basis. Das heisst, nur ausgesuchte Namespaces werden Exceptions benutzen. Dazu gehören KDE::XML, KDE::Test und KDE::IO, aber nicht KDE::Util und KDE::SLP. Damit entferne ich mich wieder einen Schritt weiter von der bestehenden KDE Codebasis, und ich weiss nicht, wohin mich das führt. Zunächst werde ich den KDE Namespace behalten und einfach weitermachen. Wenn ich irgendwann soweit bin, eine erste Version als 'fertig' zu deklarieren, kann man auf kde-core immer noch diskutieren, ob das KDE Projekt die Library adoptieren will oder eben nicht. 2003/10/04
C++ Exceptions
Ich bin wieder an dem Punkt angelangt, wo ich mit C++ Exceptions liebäugele. Bei allen APIs, die mit I/O oder dem Parsen von Daten zu tun haben, ist es fast unvermeidlich, nach jedem Aufruf einer Funktion eine Fehlerabfrage zu machen. Dadurch wird das Programm kompliziert, lang und schwer lesbar. Ausserdem ist es nicht einfach, das Design richtig hinzubekommen und im Zweifelsfall baut man diverse Fehler ein. Nachteil von C++ Exceptions, zumindest mit gcc, ist, dass die Binaries deutlich länger werden. Ausserdem kann man sie mit manueller Speicherverwaltung kaum vereinbaren, aber das ist eher ein Vorteil, weil manuelle Speicherverwaltung ohnehin bösartig ist. Bislang habe ich versucht in den APIs die regelmäßige Fehlerabfrage zu verhindern, indem die meisten Methoden einer Klasse sich einfach tot stellen nachdem ein Fehler aufgetreten ist. Aber das verkompliziert sowohl die Implementierung als auch die API, weil für jede Methode das Verhalten nach einem Fehler definiert werden und der Entwickler dieses nacher kennen und berücksichten muss. Letztenendes führt wohl für alle XML-benutzenden, Parsenden und I/O Klassen kein Weg daran vorbei... 2003/10/02
KDE 4.0
Zu den Sachen, die ich gerne für KDE 4.0 hätte, gehört die vor ein paar Monaten bereits angesprochene Sprachen-/Platformunabhängigkeit. Mike Hearn hat dazu ein paar ausführlichere Blog-Einträge geschrieben. Mit dem Fazit stimme ich allerdings nicht überein. GObject fehlt eine Menge Funktionalität, wie in meiner Advogato Antwort beschrieben. Bislang habe ich die Platformunabhängigkeit bei meinen neuen APIs nicht bedacht, aber es gibt da einige Probleme:
Ich habe derzeit keinen wirklichen Lösungvorschlag, aber zumindest was zum nachdenken... System Services Ein weiteres Thema derzeit ist Seth Nickel's System Services Konzept, das die guten alten init Scripts ablösen soll. Im Prinzip halte ich es für keine dumme Idee, aber derzeit gibt es viel grundlegendere Probleme, die der Implementierung im Wege stehen: es gibt keine Bibliotheken für die meisten System-nahen Kommandozeilen-Programme. Befehle wie ifconfig oder route benutzen obskure und schlecht dokumentierte Funktionen wie ioctls(), sysctls() und das /proc Filesystem, um ihre Aufgabe zu erledigen. Und das noch platformunabhägig. cp hat recht komplizierte und schwer richtig zu bekommende Algorithmen, und dies wird noch schlimmer mit erweiterten Attributen und mit Reiser4's Metadaten. Solange diese Funktionen nicht in handlichen Libraries verfügbar sind ist das Ersetzen von init scripts nicht so einfach. |