NEWS
Javascript Synchron
-
Hallo,
ich habe die Möglichkeit gefunden die Befehle im Javascript adapter synchron auszuführen:
Es wird so was möglich sein:
setState('A', true); sleep(2000); <= sehr ungenau setState('A', false);Dabei müssen die synchrone Funktionen anders heißen.
mir fehlt nicht anders ein, als Suffix Sync
setStateSync createStateSync setObjectSync extendObjectSync ... sleepFehlt jemandem bessere Idee ein? Man kann noch statt callback einfach true schreiben oder ..
setStateEx, setStateS, setState("A", val, ack, isSync (nicht callback)) -
EIne alternative ist die Frage "was sollte für die User der Standard sein"?
ALso Vllt "setState" -> syncron und setStateAsync für die Profis? :-) `
Damit würdest du jetzt alle jemals geschriebenen Skripte inkompatibel machen, ich glaube dafür ist es zu spät. :lol: -
Hi,
ich habe es bisher vermieden states anzulegen oder zu aendern und anschliessend zu verwenden oder abzufragen, zumindest innerhalb der gerade laufenden Routinen.
Der synchrone Ablauf hat Vorteile, wenn es Abhängigkeiten gibt aber m.E. eine möglicherweise erhebliche Performanceeinbuße.
Daher würde ich nicht unbedingt standardmaessig auf synchron umschalten. Oder denke ich falsch ?
vG Looxer
-
Das finde ich super, dass jetzt die Möglichkeit der synchronen Abarbeitung geschaffen wird :D :D :D
Ich wäre eindeutig für das Suffix "Sync". Damit bleibt die Kompatibilität gewahrt und man sieht auf Anhieb was man verwendet hat. Ein (optionaler) Parameter beim Aufruf wäre zwar auch eine gangbare Möglichkeit - finde ich aber wesentlich unübersichtlicher als die Variante mit Suffix.
-
Ich wäre eindeutig für das Suffix "Sync". Damit bleibt die Kompatibilität gewahrt und man sieht auf Anhieb was man verwendet hat. Ein (optionaler) Parameter beim Aufruf wäre zwar auch eine gangbare Möglichkeit - finde ich aber wesentlich unübersichtlicher als die Variante mit Suffix. `
Dem schließe ich mich an.
@looxer01:…eine möglicherweise erhebliche Performanceeinbuße.
Daher würde ich nicht unbedingt standardmaessig auf synchron umschalten. Oder denke ich falsch ? `
Sehe ich auch so. Benötigt man die synchrone Variante wirklich ? -
Ich finde es eine gute Idee aber leider wird es nicht wirklich Synchron und einige Lewute noch mehr verwirren.
Es scheint so zu funktionieren dass nur die ioBroker-Funktionen synchron sind, aber nicht der restliche code.
Sorry, zu früh abgesendet:
Beispiel:
function inc(xxx) { var x = getState(xxx).val x = x +1; setState(xxx,x); } inc(abc); inc(abc); wird nicht funktionieren.bin eher dafür neue Dinge mit neuen NodeJS-Sprachversionen zu implementieren,
Ein Beispiel sind Promises (wie ich sie verwende) oder auch in der ganz neuen Version Yields.
-
@fsjoke:Ich finde es eine gute Idee aber leider wird es nicht wirklich Synchron und einige Lewute noch mehr verwirren.
Es scheint so zu funktionieren dass nur die ioBroker-Funktionen synchron sind, aber nicht der restliche code.
Sorry, zu früh abgesendet:
Beispiel:
function inc(xxx) { var x = getState(xxx).val x = x +1; setState(xxx,x); } inc(abc); inc(abc); wird nicht funktionieren.bin eher dafür neue Dinge mit neuen NodeJS-Sprachversionen zu implementieren,
Ein Beispiel sind Promises (wie ich sie verwende) oder auch in der ganz neuen Version Yields. `
Genau das wird gehen Synchron. -
Verstehe ich das richtig, dass das die Implementierung wird, die ich mir Anfang des Jahres gewünscht habe? Eine synchrone (Promise-) Kapselung um die asnychronen Methoden?
Denke dann macht xxxSync() Sinn, ist vom Verständnis her analog zu den NodeJS-Libraries.
-
Verstehe ich das richtig, dass das die Implementierung wird, die ich mir Anfang des Jahres gewünscht habe? Eine synchrone (Promise-) Kapselung um die asnychronen Methoden?
Denke dann macht xxxSync() Sinn, ist vom Verständnis her analog zu den NodeJS-Libraries. `
Ne.. Promise ist doch Asynchron.Es geht tatsächlich um synchrone Ausführung, damit die Leute, die aus Arduino- oder SPS- Welt kommen, immer noch zurecht kommen.