[Allegro] VuFind: Neuer Anlauf

Bernhard Eversberg ev at biblio.tu-bs.de
Di Dez 20 09:44:52 CET 2011


Am 20.12.2011 09:21, schrieb Anando Eger:
>
> Was spricht dagegen, beispielsweise Herrn Bergers update.job
> in die Standard-Auslieferungsversion von Allegro zu übernehmen?
>
Hatte ich eigentlich schon mal zu begründen versucht, aber ok:

Zuerst brauchen wir eine plausible Erklärung, warum die zusätzlichen 
Variablen $OPTS.* nötig sind, wenn sie nichts anderes umfassen und
darstellen als was in $ARGV:* schon steht, nur mit anderen, viel
längeren Benennungen. Das braucht, finde ich, eine solide
Rechtfertigung, dazu reicht mir "heutige softwaretechnogische
Standards" nicht aus, da fehlt mir das Augenmaß. So viele Zeilen mehr
als wirklich nötig, das kann man nicht ernsthaft elegant nennen.
Bedenken Sie doch, daß FLEX-Jobs immer sehr begrenzte Objekte sind,
nicht zu vergleichen mit wirklichen Programmen wie a99 oder acon
selbst. Und die Variablen haben gerade bei acon keine Lebenszeit über
das Ende des Jobs hinaus! Wenn man so etwas dann so anlegt wie ein
enormes Java-Klassengebilde, dann ist das überdimensioniert und fordert
dem, der es rezipieren will, unnötig viel Zeit ab allein für's Lesen
und dann auch für's Schreiben, wenn man die Variablen dann
verwendet. Na gut, die Namen sind "sprechend", aber eine Liste dafür
braucht man trotzdem zum Nachschauen und Abschreiben, allein wegen
der Gross-Kleinschreibung und Sonderzeichen - je länger ein Name,
umso mehr Chancen zum Verschreiben. Dann tun's die $ARGV-Namen genauso.

Ich würde, summa summarum, Bergers update.job gerne übernehmen, aber
nicht mit dem $OPTS-Overhead. So etwas braucht zumindest eine wirklich
unabweisbare Rechtfertigung, sonst nenne ich das l'art pour l'art.

B.E.




Mehr Informationen über die Mailingliste Allegro