Hi,
On Tue, Feb 20, 2018 at 09:30:02PM +0100, Thorsten Behrens wrote:
> Über Geschwindigkeiten kann man sich trefflich streiten, und über
> Möglichkeiten, Änderungen in Syntax und Verhalten zumindest zu
> bemerken kann man reden.
>
> Die Idee, dass man Software einmal schreibt, und sie dann für immer
> unverändert läuft, ist aber jedenfalls für den professionellen Einsatz
> nicht haltbar.
Genau.
> Ich verstehe schon den Frust - aber es gibt eigentlich keine
> API-Änderungen, die 'nur mal eben so' gemacht werden. Normalerweise
> sind das Bugfixes oder Umbauten für neue Features, die dann leider
> Seiteneffekte haben.
Ja. Es ist, glaube ich, auch in den meisten Faellen fuer einen Entwickler der
an LibreOffice arbeitet, auch bei bester Umsicht nicht zur Erfahrung zu
bringen, ob es relevante Seiteneffekte gibt und ob diese bestehende Extensions
brechen. "Seiteneffekte" klingen hierbei offensichtlich -- sie sind es aber im
allgemeinen nicht.
Ein Paradebeispiel ist eine Aenderung, welche LibreOffice schneller macht indem
bestimme Datenstrukturen nicht mehr in einer bestimmten Reihenfolge gehalten
werden. LibreOffice schneller zu machen ist sicher im allgemeinen Interesse,
und wenn die API-Beschreibung nicht explizit eine Reihenfolge vorgibt auch
formell nicht verwerflich.
Allein, viele Extensions und Macros verlassen sich wissentlich oder
unwissentlich auf solche Annahmen. Ich bin mir sicher, _mindestens_ 2/3 der
Dinge, die durch Aenderungen in Extensions kaputt gehen, liegen daran, dass die
Extensions sich auf implizite Annahmen verlassen haben[1].
Nun koennte man das verbleibende Drittel optimieren, und _formell_ nie die
versprochene API aendern. In der Praxis wuerde dies wenig aendern: Die
verbleibenden 2/3 sind genug.
IMHO ist eine Loesung hier einen Korpus von testbaren Extensions/Macros usw. zu
schaffen, der der Nutzung von LibreOffice APIs in der freien Wildbahn
einigermassen abdeckt. Diese Korpua von Tests, sollte automatisierbar sein,
d.h. z.B. letztendlich jeweils eine Funktion die Null oder Eins zurueckgibt
(Null = alles ist so wie erwaertet, Eins = etwas unerwartetes hat sich an der
API geaendert. So ein Korpus kann kaum von LibreOffice Core Entwicklern
gepflegt und aufgebaut werden, weil kaum Zeit fuer Macro- oder
Extensionprogrammierung haben. Der Korpus muesste gepflegt werden von Leuten,
die die API selbst regelmaeesig benutzen und wissen, welche Nutzung der API in
der Community ueblich ist.
Ein solcher Korpus von API-Tests wuerde, wenn er regelmaessig gegen den
LibreOffice master Branch laeuft:
- frueher bekannt machen, wo/wann in der Macrocommunity haeufig benutzte Muster
von
Aenderungen betroffen sind.
- kombiniert mit Werkzeugen wie bibisect schnell klar machen, warum/wodurch die
Aenderung erfolgt ist.
- damit eine qualifizierte Entscheidung oder Abwaegung der Aenderung
ermoeglichen.
- ggf, eine Loesung zu finden, die sowohl die ueblichen Annahmen der API-Nutzer
als auch die Gruende der Aenderung selbst beruecksichtigt.
- damit ebenfalls ermoeglichen in Faellen, wo die Aenderung beibehalten wird,
schon bei der Release klare Handlungsanweisungen mitzugeben (z.B.
"Macros-Code mag bisher angenommen haben, dass der Aufruf von ABC an XYZ nach
DEF sortierte Objekte zurueckliefert. Dies ist nicht mehr der Fall, aber hier
ist Beispielcode um damit umzugehen."
Entscheidend aber ist: Es muss jemand machen. Und es muss jemand machen, der
selbst die Extension-API und die Nutzer der Extension-API kennt. Andere
Ressourcen, z.B. Hardware, welche diese Tests dann regelmaessig ausfuehrt, sind
sicher weniger ein Problem.
Gruss,
Bjoern
[1] Auch das ist nicht verwerflich: Es ist verdammt schwer als Mensch keine
impliziten Annahmen zu machen.
--
Liste abmelden mit E-Mail an: discuss+unsubscr...@de.libreoffice.org
Probleme?
https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/discuss/
Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert
