Rekursiver Algorithmus über Callbackfunktion

[Rolf B]

Hallo pl,

wat weiß ich denn dass Du direkt vor der Kiste hockst und auf mein Posting wartest? 😉

Aber: jetzt revokest Du erstmal gar nicht mehr - sicher weißt Du, dass das bei SPA Seiten nicht gut ist. Wenn die Seite entladen wird (das document gelöscht wird), revoked der Browser die URLs, aber du hast einen Button zum mehrfachen Laden und mit jedem Klick gehen Ressourcen fliegen, wenn Du nicht revokest. Da brauchst Du einen handgemachten Müllsammler.

Zu deinem Aufsatz zur Serialisierung: Diese Diskussion ist alt, älter als SelfHTML. Du setzt einfach einen ganz anderen Schwerpunkt als andere und kommst daher auch zu anderen Ergebnissen. Für deinen Zweck und für viele andere Zwecke ist die von Dir vorgestellte Technik zielführend. JSON und XML verfolgen aber einen breiteren Ansatz. Zwei Dinge, die Du als selbstverständlich voraussetzt, werden von JSON und XML ganz bewusst NICHT vorausgesetzt: Endianität und Zeichencodierung. JSON und XML sind Textformate, um die binäre Repräsentation irgendwelcher Werte ausdrücklich NICHT voraussetzen zu müssen. Der Endian ist ja nur ein Aspekt. Zum Beispiel speichert nicht jedes System Dezimalzahlen als IEEE 754 Floats. Und die Textformate machen keine Aussage über die Codierung von Zeichen. Du setzt UTF-8 voraus, was eine häufige, aber nicht universelle Variante der Unicode-Darstellung ist. Es gibt noch UTF-16 und UTF-32, jeweils als BE und LE, und wenn das Dokument einen bestimmten Zeichenvorrat nutzt, spricht auch nichts dagegen, für die Speicherung Latin-1, ASCII oder EBCDIC zu nutzen. All das ist in JSON und XML möglich; eine Übersetzung von der einen Codierung in eine andere ist möglich, ohne die Dokumentstruktur zu kennen und ohne in die Software einzugreifen, die sich um die Decodierung kümmert. Das ist bei deinem Ansatz nicht möglich, du legst bestimmte Parameter fest und eine Transcodierung setzt voraus, dass man dein Serialisierungslayout kennt. Damit lässt Du einen einen der wichtigeren Ansätze des Software Engineerings beiseite: Separation of Concerns.

Eine geringere Abstraktion erzeugt fast immer einfacheren Code. Und SE-Prinzipien wegzulassen bringt fast immer Laufzeitvorteile. SE Prinzipien verfolgen ja auch nicht das Ziel, möglichst kleine und schnelle Programme zu produzieren. Wenn man das wollte, würde man heute noch alles in Assembler schreiben. Man merkt Programmierern oft an, mit welcher Sprache sie angefangen haben. Ein guter Assemblerprogrammierer baut auch in Java noch Sprungtabellen, und ein guter COBOL Programmierer organisiert auch in C# alle Daten als WORKING-STORAGE SECTION und holt Funktionsergebnisse als ref-Parameter ab (selbst wenn sie in einem Objekt stecken). Ein guter C# Programmierer, der vor einem COBOL Compiler sitzt, bekommt nach 5 Minuten Kopfschmerzen, und ein 80er Jahre Programmierer braucht einige Behandlungen mit dem Holzhammer, bevor er einsieht, dass Laufzeit billiger ist als die Zeit, die man mit dem Schreiben und Pflegen der Software verbringt.

Software Engineering verfolgt das Ziel, Software so modular wie möglich zu machen und Kopplungen zwischen den Bausteinen zu minimieren. Das tut sie, seit man von Assembler nach Fortran und COBOL gewechselt hat, und es ist mit Sprachen wie Erlang oder Haskell sicherlich noch nicht zu Ende. Die Programme werden dadurch langsamer. Sie werden auch größer. Aber Systeme einer gewissen Größe werden dadurch überhaupt erst realisier- und wartbar.

Rolf