[Allegro] Re: a99 v29.3 und i4=5

[Bernhard Eversberg]

Thomas Berger schrieb:

>> Nun, dann scheint's mir doch jetzt besser so - oder was spricht dagegen?
>> B.E.
> 
> [Kompatiblitaet mit den Versionen V14.x - V23.2 koennte ein Kriterium
> zur Beurteilung von "besser" sein ;-]
> 
Nein. Kompatiblität nur um ihrer selbst willen lassen wir nicht gelten
(Die Devise ist, "Lasset uns am alten, *so es gut ist*, halten"! Wobei
wir "so es gut ist" auch schon mal abschwächen zu "so es nützet".)

> Mischung der Formen _schluessel und _schluessel_ in einer Datenbank
> sollte eigentlich nicht vorkommen (denn sonst waere beim "_" /hinter/
> "_schluessel" nicht klar, ob es sich nicht um ein intendiertes "_"
> /vor/ etwas anderem handelt).
> 
> Vor allem ist aber wichtig, nach der Ersetzung die Verbindung
> zwischen beibehaltener Identnummer _schluessel und dem Ersetzungstext
> erkennen zu koennen. In der aktuellen Form mit " " koennte es sich
> ja auch um eine nicht aufloesbar gewesene Ersetzung gehandelt
> haben, gefolgt von Originaltext aus der Kategorie.
> 
> Insofern ist die jetztige Loesung eher schlechter als die vorige.
> 
Dem ist hingegen zuzustimmen und es ließe sich ein Handlungsbedarf
daraus ableiten, die Frage ist nur noch dessen Stufe.

> Auch die alte Variante _schluessel_Ersetzungstext ist zugegebenermassen
> nicht optimal, man wuerde sich zusaetzlich eine Kennzeichnung wuenschen,
> wo der Ersetzungstext endet und es weiter im Original-Text der Kategorie
> geht. Ich setze zwar meist per Indexparametrierung noch ein spezielles (durch
> die Umcodierungen dann automatisch vernichtetes) Steuerzeichen hinten an den
> Ersetzungsschluessel im Index, die Loesung scheitert dann aber
> (Koerperschaftsansetzungen!), wenn der Index nicht in der Lage ist, den vollen
> Ersetzungsschluessel zu liefern.
> 
> Wenn sich hier eine Verbesserung finden liesse, faende ich Inkompatibilitaet
> mit frueheren Versionen nicht so tragisch.
> 
Wir schauen mal, was die Mitbewerber in diesen Dingen leisten,
vielleicht können wir da was abkupfern ...

B.E.