On Saturday 20 April 2002 21:53, Torsten Werner wrote:
Das ist natürlich ein Argument, gegen das schwer anzukämpfen ist. Ich bin halt der Meinung, dass es prinzipiell möglich sein muss, den Vulkan zu stoppen oder was auch immer man noch Vulkanen antun kann.
Zu DDR-Zeiten hätte man eine Mauer drum gebaut und das dann zum Standard erklärt :)
Das ist aber extrem fehleranfällig. Stell dir vor ich entferne die Parameter, weil ich der Meinung bin, ich bräuchte sie gar nicht. Normalerweise würde mich der Compiler dafür ohrfeigen, aber bei Qt kann ich nur hoffen, dass die Dummheit zur Laufzeit auffällt. Wenn es in 99 % der Fälle glatt läuft, habe ich ein Problem, den Fehler zu finden. Ergo, mir gefällt die statische Typprüfung in C++.
Deine beiden Hauptargumente gegen Signals/Slots sind Langsamkeit und nicht gegebene Typsicherheit. Gegen das erste läßt sich wenig ausrichten (das ist so vom Design her, asynchron ausgerichtet...), aber zumindest die Typsicherheit könnte man (auf Kosten der Compilezeit) erzwingen, indem z.B. eine all-am-local Regel ins Makefile.am eingefügt wird (oder was äquivalentes), die alle Sourcen, die sich verändert haben, nochmal durchparst. Den moc aufzubohren würde hier nichts bringen, aber den cpp verwenden oder kdoc aufbohren (was sowieso schon auf Signals/Slots angepasst ist und z.B. für die Java-Bindings-Generierung verwendet wird) sollte möglich sein. (jaja, die Konjunktive wieder...)
Ein aufgelöstes Makro von Konsole sieht etwa so aus:
connect( em, "2""notifySessionState(int)" , this, "1""notifySessionState(int)" );
2 Dinge wären nun zu überprüfen: - stimmen die Parameter überein? (einfach) - werden sie genau so vom Signal und Slot angeboten? (schwierig, weil über Klassen/Dateien hinweg geprüft werde müßte)
Aber ich selbst bin auch recht zufrieden mit dem jetzigen Konzept. Vor allem halte ich Qt zugute daß es relativ konsistent geblieben ist. 30'000 Zeilen Qt/KDE-basierten Code an zwei Tagen zu portieren (Qt 2.1/2.2 -> 3.0), und zusätzlich nochmal 70'000 Zeilen an einem Tag (threedom.sourceforge.net), das wäre mit anderen Toolkits sicher mächtig in die Hose gegangen. Ein wenig Bash/Sed war allerdings auch mit dabei ;)
Josef Spillner