Pro & Kontra zu Änderungen bestehender (Skript)-Funktionen

[msl]

Hallo,

aus aktuellem Anlass möchte ich die Diskussion zu Veränderungen bestehender CHDK-Funktionen an dieser Stelle weiterführen.

viewtopic.php?f=13&t=3174&p=29829#p29829
viewtopic.php?f=7&t=3360&p=29850#p29849 ff

Prinzipiell versuchen die CHDK-Entwicker Dinge wie Umbenennung/Änderung bestehender Skriptfunktionen zu vermeiden. In der Release-Version (gegenwärtig CHDK 1.2) wird solche Änderungen nicht oder nur im Fall grober Fehler geben. Bei der Vorschau-Version (gegenwärtig CHDK 1.3) kann das schon eher vorkommen.

Die Vorschauversion ist die Entwicklerversion. Da werden neue Funktionen eingeführt. Diese können u.U. durch gewonnene Praxiserfahrungen geändert werden. Wir hatten den Fall, als die Version 1.2 Entwicklerversion war, dass die CHDK-Menübedienung mehrfach geändert wurde.

Ärgerlich sind solche Änderungen, wenn es um Skriptfunktionen geht. Hier kann eine ganze Kettenreaktion ausgelöst werden. Es lässt sich aber nicht immer vermeiden. Die CHDK-Entwickler handeln dabei auch nicht leichtfertig. Im Fall Umbenennung enable_highspeed_usb in enable_remote_hp_timer wurde nächtelang über das Für und Wider diskutiert. Schlussendlich kam ein etwas unglücklicher Name heraus, der den Endanwender nicht unbedingt etwas über den Sinn dieser Funktion sagt.

Ein anderes Problem ist die Veränderung von Rückgabewerten. Hier geht es um standardisierte Grundlagen. Diese sollten möglichst eingehalten werden.

Wenn eine Funktion je nach Zustand 0 oder 1 zurück gibt, ist das in vielen Programmiersprachen kein Problem, da dies auch gleichbedeutend mit den Booleschen Werten falsch(false) und wahr(true) ist. In Lua sieht es da etwas anders aus. Da ist auch 0 wahr. Deshalb ist eine Änderung von 0/1 in false/true eine richtige Entscheidung.

Der Skriptbefehl set_mf() hat da ein ähnliches Problem. Auch hier wird 0/1 zurückgegeben. Das sollte auch in false/true geändert werden.

Um die Qualität von CHDK zu verbessern, sollten aus meiner Sicht solche Änderungen in der Entwicklerversion in jedem Fall durchgeführt werden. Das ist für alle engagierten Skriptautoren sehr ärgerlich, aber aus meiner Sicht trotzdem notwendig.

Gruß msl

[c_joerg]

Hallo,

ich möchte mich zu diesem Thema auch kurz zu Wort melden.
Ich arbeite seit 25 Jahren in der Entwicklung für Signalverarbeitungsalgorithmen, meine also zu wissen, wovon ich spreche.

Das umbenennen von vorhandene Funktionen oder das Ändern von Rückgabewerte ist in der kommerzielle Softwareentwicklung ein absolutes ‚No Go‘. Das umbenennen bekommt ein Compiler ja meist noch mit aber das mit den Rückgabewerten…

Wenn das Umbenennen nun unbedingt notwendig ist, dann geht man normalerweise so vor:
Wenn z.B. die alte Funktion xyz heißt, dann bleibt sie auch wie folgt erhalten:

Code: Alles auswählen

function xyz()
  Print(„Hinweis dass man die neue Funktion benutzen soll“)
  xyz_neu()
end


Auch Rückgabe Parameter lassen sich so umsetzen.

Grüße Jörg

[Werner_O]

Hallo msl,

es war eine gute Idee von Dir, zu diesem Thema einen neuen Thread einzurichten, damit das mal öffentlich und separat diskutiert werden kann.

Meine eigene Meinung dazu hatte ich ja bereits hier gepostet.

Ein anderes Problem ist die Veränderung von Rückgabewerten. Hier geht es um standardisierte Grundlagen. Diese sollten möglichst eingehalten werden.
Wenn eine Funktion je nach Zustand 0 oder 1 zurück gibt, ist das in vielen Programmiersprachen kein Problem, da dies auch gleichbedeutend mit den Booleschen Werten falsch(false) und wahr(true) ist. In Lua sieht es da etwas anders aus. Da ist auch 0 wahr. Deshalb ist eine Änderung von 0/1 in false/true eine richtige Entscheidung.

Im Prinzip ist es doch Jacke wie Hose, ob ich als Programmierer 0/1 oder false/true abfrage wenn ich weiß, was ich abfragen soll.
Mein alter programmierbarer HP-Taschenrechner HP48 kennt dabei sogar gar kein true/false, sondern verwendet immer nur 0 oder einen von 0 abweichendenen Wert für solche Abfragen. Programmtechnisch gesehen ist das aber kein Problem, auch nicht bei Lua.

Der für mich einzig ersichtliche Vorteil von Booleschen Werten ist die mögliche Reduzierung des Codes:
Bei Verwendung von 0/1 sieht der bspw. so aus

Code: Alles auswählen

Bedingung = 1
if Bedingung == 1 then <Befehl> end

Bei Verwendung von true/false kann der Code dagegen minimal reduziert werden

Code: Alles auswählen

Bedingung = true
if Bedingung then <Befehl> end

Rein funktional gibt es dabei aber keinen Unterschied.

Der Skriptbefehl set_mf() hat da ein ähnliches Problem. Auch hier wird 0/1 zurückgegeben.
Das sollte auch in false/true geändert werden.

Hier muss ich fragen: auf wessen Kosten?
Alle bisher weltweit geschriebenen Skripte mit diesem Befehl würden so auf einen Schlag unbrauchbar.
Ist dieser hohe Preis darum überhaupt irgendwie zu rechtfertigen? Letztendlich müssen das ja die vielen CHDK-User ausbaden.

Im Grunde sind diese Probleme ja von der CHDK-Entwicklergemeinde selbstverschuldet, da neue Funktionen eingeführt wurden mit nur entweder möglich/unmöglich, mit aber 0/1 als Rückgabewert anstelle von false/true.
M.E. sollte darüber mal im internationalen Forum diskutiert werden. Wenn da jeder machen kann was er will und sich nicht an die standardisierten Grundlagen hält, kann daraus auch kein "gemeinsamer CHDK-Schuh" werden.

Jetzt nachträglich bereits seit Monaten eingeführte neue CHDK-Funktionen ändern zu wollen halte ich aber wie c_joerg für ein absolutes "No-Go"!

Liebe Grüße
Werner_O

[msl]

Hallo,

ich sehe die Sache etwas anders. Eine Sache als "NoGo" zu charakterisieren, ist einfach. Habt ihr euch auch mal mit den Hintergründen beschäftigt?

Wenn es um ein kommerzielles Produkt ginge und wir von einer Release-Version sprechen würden, dann wäre ein "NoGo" die richtige Einschätzung. Da darf ich dann an dieser Stelle auch mal daran erinnern, dass uns selbst die Giganten der IT-Branche mit permanenten Änderungen der Funktionalität traktieren, dass wir rund um die Uhr mit irgendwelchen Updates beglückt werden und dass wir auch gerne als Beta-Tester von Release-Kandidaten benutzt werden.

Wir reden hier aber von einem Open-Source-Projekt, das ohne jeglichen kommerziellen Hintergrund, weltweit von engagierten Leuten als Hobby- und Freizeit-Projekt betrieben wird. Jeder, der Lust und Laune hat, kann sich beteiligen. Das hat aber auch zur Folge, dass nicht alles straff organisiert und nach aufgestellten Regeln funktioniert. Die CHDK-Macher lernen aber auch dazu.

So wurde mit CHDK-Version 1.0 ein zweigleisiges System eingeführt. Der Endanwender bekommt ein stabile Release-Version und eine Vorschauversion mit den neuesten Entwicklung zur Verfügung gestellt. Die Release-Version erhält nur noch Korrekturen, wenn ein grober Fehler festgestellt wurde.

Für die Vorschauversion gilt als vereinbart, dass neu eingeführte Funktionen in ihren Eigenschaften verändert werden dürfen oder auch rückgängig gemacht werden können. An der Stelle sei auch daran erinnert, dass es u.a. ziemlich schwierig ist, bei mehr als 120 Kameramodellen sicherzustellen, dass alles reibungslos funktioniert.

Bei Änderungen oder Neuerungen zur allgemeinen Funktionalität von CHDK wird sehr darauf geachtet, dass es keine Kompatibilitätsprobleme gibt. Das gilt generell auch für die Skriptfunktionen. Oft genug wurde über den Verbleib von uBASIC diskutiert. Eigentlich sind zwei Skriptsprachen eine zu viel. Auch hier wurde entschieden, dass uBASIC weiterhin parallel zu Lua aus Kompatibilitätsgründen bestehen bleibt.

Für das CHDK-Lua gilt, dass man sich bei der Entwicklung möglichst an das Lua-Konzept hält. Und da ist es bei den Rückgabewerten der genannten Funktionen zu einem Missverständnis gekommen (C-Syntax ist nicht gleich Lua-Syntax). Dieses Missverständnis könnte nun in der Vorschau(Entwickler)-Version schnell korrigiert werden. Irgendwann sollten wir anfangen, dass Lua-Konzept konsequent zu beachten.

Es ist nicht egal, ob die Rückgabewerte numerisch oder boolesch sind. Die Unterschiede sind gravierender als oben dargestellt.

Syntax: [ Download ] [ Verstecken ]

Syntax: [ Download ] [ Zeigen ]

Benutze Lua Syntax Highlighting

--alt
is_mf = set_mf(1)
if is_mf == 1 then
    set_focus(value)
end
--neu
if set_mf(1) then set_focus(value) end

Erstellt in 0.006 Sekunden, mit GeSHi 1.0.8.9

Neben der deutlich verkürzten Syntax wird Speicher gespart.

Soweit ein paar Gedanken zu "NoGo" und CHDK.

Gruß msl

[c_joerg]

Hallo msl,

Neben der deutlich verkürzten Syntax wird Speicher gespart.

müsste der Vergleich nicht eher so aussehen:

Code: Alles auswählen

if set_mf(1) == 1 then set_focus(value) end
--neu
if set_mf(1) then set_focus(value) end

Dann sieht der Unterschied nicht mehr so deutlich aus.
Wird bei diesem Vergleich auch Speicher gespart?


Grüße Jörg

[Werner_O]

Hallo msl,

mir ist klar, daß jede Münze zwei Seiten hat und es somit auch für Deine Sichtweise durchaus überzeugende Argumente gibt.

Für das CHDK-Lua gilt, dass man sich bei der Entwicklung möglichst an das Lua-Konzept hält. Und da ist es bei den Rückgabewerten der genannten Funktionen zu einem Missverständnis gekommen (C-Syntax ist nicht gleich Lua-Syntax). Dieses Missverständnis könnte nun in der Vorschau(Entwickler)-Version schnell korrigiert werden. Irgendwann sollten wir anfangen, dass Lua-Konzept konsequent zu beachten.

Das Wort Irgendwann löst bei mir dabei die Befürchtung aus, daß eine Umstellung der betroffenen Befehle schrittweise in diversen CHDK-Versionen erfolgen könnte, was dann kaum noch nachvollziehbar wäre.

Wenn also umgestellt wird, sollten alle nötigen Änderungen simultan ausgeführt werden, die dann ab CHDK 1.3 vXXXX gültig sind. Davor sollte man das bisherige CHDK 1.3 aber auch auf "Altleichen" untersuchen, und erst danach sozusagen "Tabula rasa" machen.

Zusätzlich muß danach eine web-Adresse eingerichtet werden, die über alle vorgenommenen Änderungen informiert.
Dort muß es dann eine Aufstellung zu allen Lua-Befehlen geben, die geändert wurden.

Außerdem müßte auch die so wichtige Website CHDK Scripting Cross Reference Page - CHDK Wiki diesbezüglich aktualisiert werden, wobei man diese Arbeit aber nicht rein auf den Bereitsteller dieser Seite (m.W. waterwingz) abwälzen darf. GsD kann man sich ja dort registrieren und dann auch Änderungen vornehmen.

Mein Fazit darum:
Eine Umstellung sollte darum sorgfältig geplant sein und dann auch gleich "Nägel mit Köpfen" machen.
Eine neue CHDK-Version 1.3 ab vXXXX muß dann ein verläßliches Fundament für Programmierer sein.
Neue CHDK-Funktionen sollten nur dann zugelassen werden, wenn sie sozusagen "regelkonform" sind.

Liebe Grüße
Werner_O

[msl]

Hallo,

müsste der Vergleich nicht eher so aussehen...
...Wird bei diesem Vergleich auch Speicher gespart?

2x ja. Ich hatte für das allgemeine Verständnis zusätzlich eine numerische Variable deklariert. Das ist aber eigentlich überflüssig. Eine Einsparung an Speicherplatz erfolgt in jedem Fall.

Wenn also umgestellt wird, sollten alle nötigen Änderungen simultan ausgeführt werden, die dann ab CHDK 1.3 vXXXX gültig sind. Davor sollte man das bisherige CHDK 1.3 aber auch auf "Altleichen" untersuchen, und erst danach sozusagen "Tabula rasa" machen.

Zusätzlich muß danach eine web-Adresse eingerichtet werden...
Dort muß es dann eine Aufstellung ...
Außerdem müßte auch die so wichtige ...

Es betrifft doch nur set_mf() als neuen Lua-Befehl in der Version 1.3. Alle andere kameraspezifische Lua-Befehle, bei denen ein boolescher Rückgabewert Sinn machen würde, sind älter. Kandidaten wären z.B. set_aflock() und set_aelock(). Das müsste dann wirklich diskutiert werden.

Was die Seite der Dokumentation betrifft, sind alle aufgerufen, sich zu beteiligen. Bei so einem Projekt wird die Dokumentation immer zum notwendigen Ãœbel. Diejenigen, die Manuale schreiben, brauchen sie eigentlich nicht. Und diejenigen, die sie lesen sollten, haben oft keine Lust zum Lesen.

Gruß msl