Validierungsschema: welche Funktionen werden invalid, welche nicht?

[Tessi]

Hallo allerseits,

soweit ich es gelesen und behalten habe, steht im Handbuch bei keiner Funktion ein Hinweis, ob sie bei Änderungen ihrer Argumente erneut ausgewertet wird, oder nicht, demnach würde ich erwarten, das alle gemäß dem Kapitel über das Validierungsschema reagieren:
Funktionen zur Verarbeitung werden durch ihre Argumente invalid, Funktionen zu zur Ausgabe und Zeitfunktionen dagegen nicht.

Aber zu welcher Kategorie gehören stringcast() und stringset()?

In der Referent werden sie unter Stringfunktionen geführt, aber stuft man die jetzt unter Verarbeitung oder Ein-/Ausgabe ein?

Da die Frage auch bei anderen Funktionen auftreten kann/wird, würde
ich mir wünschen, das der Dokumentation für jede Funktion eindeutig entnommen werden kann, ob diese invalid wird, oder nicht.

[enertegus]

Hallo allerseits,
soweit ich es gelesen und behalten habe, steht im Handbuch bei keiner Funktion ein Hinweis, ob sie bei Änderungen ihrer Argumente erneut ausgewertet wird, oder nicht, demnach würde ich erwarten, das alle gemäß dem Kapitel über das Validierungsschema reagieren:

Alle Funktionen, die schreiben oder was verändern, werden nicht von ihren Argumenten abhängig ungültig. Um diese zum Schreiben zu "animieren", muss daher diese Art von Funktionen immer im then Zweig einer if-Anweisung stehen.

[Tessi]

Bedeutet das, stringset() wird nicht invalidiert, weil es implizit eines seiner Argumente verändert, stringcast() dagegen schon, weil es wie z.B. sin() ein Ergebnis zur freien Verwendung liefert, aber direkt nichts verändert/schreibt?
Oder habe ich da was falsch verstanden?

[enertegus]

Bedeutet das, stringset() wird nicht invalidiert, weil es implizit eines seiner Argumente verändert, stringcast() dagegen schon, weil es wie z.B. sin() ein Ergebnis zur freien Verwendung liefert, aber direkt nichts verändert/schreibt?

Ja.

Wir haben die Validierung in der aktuellen Version nochmals komplett überarbeitet. In der derzeitigen Beta wird dann kein Ausdruck im then Zweig einer if Funktion mehr invalid, solange nicht die if-Bedingung in der Verabeitung erfüllt ist. Dies führt zu besser verständlichen Initialisierung und macht einiges an Performance aus.

[saft6luck]

Wir haben die Validierung in der aktuellen Version nochmals komplett überarbeitet. In der derzeitigen Beta wird dann kein Ausdruck im then Zweig einer if Funktion mehr invalid, solange nicht die if-Bedingung in der Verabeitung erfüllt ist. Dies führt zu besser verständlichen Initialisierung und macht einiges an Performance aus.

Auch wenn es noch zu früh ist, da Beta:
- wird der then-Zweig noch im gleichen Zyklus abgearbeitet?
- ist damit das "Problem" behoben, dass unter manchen Bedingungen Code erst einen Zyklus später bearbeitet wird?
- ist die eval()-Funktion betroffen?

[enertegus]

Auch wenn es noch zu früh ist, da Beta:
- wird der then-Zweig noch im gleichen Zyklus abgearbeitet?
- ist damit das "Problem" behoben, dass unter manchen Bedingungen Code erst einen Zyklus später bearbeitet wird?

Es ist damit zweierlei erledigt:
- Initialisierungsproblem, siehe hier: https://knx-user-forum.de/144608-post279.html
- events in then-Zweigen, die gar nicht ausgeführt werden.

Mit "Zyklus später" meinst Du vielleicht die change()-Funktion. Diese wurde aber nicht geändert. Insgesamt soll ja das Verhalten gleich sein, nur an den Stellen, die zugegebenermaßen nicht "rund" waren, soll das nun der Fall sein (Diskussionsbedarf über die Validierung an sich hab ich nicht).

- ist die eval()-Funktion betroffen?

hier wurde nichts geändert.

[Tessi]

Ja.

Nur zur Sicherheit:
Bei

var1=stringcast(String, Data, Pos)

wird var1 immer dann automatisch neu bestimmt, wenn String und/oder Pos ihren Wert ändern? (Ich gehe mal davon aus, das der Typ von Data sich nicht ändern kann/darf und der Wert ja egal ist, Data also nicht triggern kann)

Ich meine, das kann heftige Konsequenzen haben:
Angenommen, ich lade zur Initialisierung 1000 Variablen aus einem String und nun modifiziere ich ein Byte dieses Strings per stringset(), werden dann schlagartig alle 1000 Variablen neu geladen? (dürfte den betroffenen Zyklus um einiges länger werden lassen) Aber nur die sich tatsächlich ändernde Variable wird invalid und triggert die abhängigen Ausdrücke?

Wir haben die Validierung in der aktuellen Version nochmals komplett überarbeitet. In der derzeitigen Beta wird dann kein Ausdruck im then Zweig einer if Funktion mehr invalid, solange nicht die if-Bedingung in der Verabeitung erfüllt ist. Dies führt zu besser verständlichen Initialisierung und macht einiges an Performance aus.

Oh, ich dachte, das war schon immer so...
Ich hatte es so verstanden, das nur auf der aller obersten Ebene, also in der Abfrage der äußersten if Funktion und bei unbedingten Ausdrücken validiert wird, alles darunter aber statisch ausgewertet wird und das nur dann, wenn man in den betreffenden Zweig kommt...

Und gilt analog nun auch, das kein Ausdruck im else Zweig einer if Funktion mehr invalid wird, solange die if-Bedingung in der Verabeitung erfüllt ist?

[saft6luck]

Mit "Zyklus später" meinst Du vielleicht die change()-Funktion. Diese wurde aber nicht geändert.

Ja, führt zu unberechenbaren Ketten-Events. Ist für mich einer der wenigen Fälle, wo das Validierungsschema sichtbar "unrund" ist, zusammen mit der fragwürdigen Implementierung des "else".

Insgesamt soll ja das Verhalten gleich sein, nur an den Stellen, die zugegebenermaßen nicht "rund" waren, soll das nun der Fall sein

D.h. du beschreibst etwas im Validierungsschema, was sowieso niemand sehen kann, nur damit es alle verwirrt ... und dann nimmst du es raus ... *tataaaa*, weil es ja nichts ändert und auch nichts geändert werden soll?! Aber dafür ist jetzt alles rund?

Gibt es dann wenigstens ein Update im Handbuch?

(Diskussionsbedarf über die Validierung an sich hab ich nicht).

Dito.

[saft6luck]

Und gilt analog nun auch, das kein Ausdruck im else Zweig einer if Funktion mehr invalid wird, solange die if-Bedingung in der Verabeitung erfüllt ist?

Da der 'else'-Zweig als zweites if mit negiertem Ausdruck implementiert ist ...

Die Änderung bedeutet wohl nur, dass die Anweisungen im 'then'-Zweig nicht schon bei der Änderung eines Inputs der Abfragebedingung 'invalidiert' verden, sondern erst, wenn der 'then'-Zweig tatsächlich ausgeführt werden muss. Eine 'pauschale' Statusänderung wird zu einer 'bedingten' Statusänderung -> spart u.U. etwas Rechenzeit.

[Tessi]

Da der 'else'-Zweig als zweites if mit negiertem Ausdruck implementiert ist ...

OK, dann ist es klar, war mir irgendwie jetzt entfallen...

Die Änderung bedeutet wohl nur, dass die Anweisungen im 'then'-Zweig nicht schon bei der Änderung eines Inputs der Abfragebedingung 'invalidiert' verden, sondern erst, wenn der 'then'-Zweig tatsächlich ausgeführt werden muss. Eine 'pauschale' Statusänderung wird zu einer 'bedingten' Statusänderung -> spart u.U. etwas Rechenzeit.

Wobei mir jetzt immer noch nicht ganz klar wird, warum das einen Unterschied im von außen beobachtbaren Verhalten bedeuten kann, da zählt doch letztlich nur die Ausführung selbst, nicht der Weg dahin, oder habe ich was übersehen?

[saft6luck]

Wobei mir jetzt immer noch nicht ganz klar wird, warum das einen Unterschied im von außen beobachtbaren Verhalten bedeuten kann, da zählt doch letztlich nur die Ausführung selbst, nicht der Weg dahin, oder habe ich was übersehen?

Genau, das versteh ich auch nicht.

Die Änderung wird aber bestimmt notwendig gewesen sein (kostet ja Geld), wichtiger als z.B. den Syntax von notwendigen oder hinreichenden Strichpunkten (oder Zeilenvorschüben) zu vereinfachen, wie auch den Klammer-Quatsch oder die hundert tauschend typ-casts oder ein paar String-Funktionen, Feldzugriffe (Arrays) und richtige Makros, mit denen man jeden Text ersetzen kann einzubauen, Funktionen für die zig, ständig benötigten und somit integrierbaren Makros, etc. etc. etc. - den Teil, den man andauernd sieht und mit dem man sich ständig abmühen darf.

[Tessi]

Nun ja, das die "Sprache" ziemlich eigenwillig ist, und erhebliches Potential zur Verbesserung enthält, das wurde und wird ja schon länger und kontrovers diskutiert. Und einen "richtigen" universellen Preprozessor wünschen wir uns ja auch schon länger...
Aber letztlich haben wir es ja durch den Erwerb einen EibPCs so akzeptiert. Und das ist nun mal das Feedback mit der höchsten Gewichtung.

[saft6luck]

Aber letztlich haben wir es ja durch den Erwerb einen EibPCs so akzeptiert. Und das ist nun mal das Feedback mit der höchsten Gewichtung.

Na, du bist sicherlich nicht im Verkauf tätig. Nach deiner Vorstellung gäbe es keinen Nachfolger von Win98, denn 90% aller PCs hatten es drauf und warum soll man dann nachbessern, wenn doch eh die Käufer entschieden haben?

Oder anders ausgedrückt: Wenn ich als Nutzer nicht zufrieden bin, werde ich den eibPC auch nicht empfehlen, gekauft habe ich ihn schon -> Stichwort: Multiplikator. Da frag ich mich dann, was meine "Kaufentscheidung" dann für eine Aussagekraft hat?

[Tessi]

Dein Kauf kann zweierlei aussagen. Entweder war Dir das Gerät trotz aller Kritikpunkte gut genug, oder Du hast blauäugig die Katze im Sack gekauft...

[saft6luck]

Dein Kauf kann zweierlei aussagen. Entweder war Dir das Gerät trotz aller Kritikpunkte gut genug, oder Du hast blauäugig die Katze im Sack gekauft...

Du hast zwar nun immer noch erst 2 weitere Möglichkeiten erkannt, sie belegen aber schon wie falsch es ist, zu glauben, dass Verkaufszahlen belegen wie gut ein Produkt (nicht nur im Detail) ist.