' schrieb:Eine Klasse ist, wie du ja weist, eine Ansammlung von Methoden, Events, Propertys und Feldern, also gekapselten Daten. Genau dieses kannst du auch mit einem SubVI machen - und zwar so, dass kein Außenstehender was von den Methoden und Feldern sieht. Propertys kann man durch Enumeratoren und Variant-Ein/Ausgängen realsieren. "Globale Variablen" kann man auch mit einem SubVI machen: Schieberegister in While-Schleife.
Ah, ok, jetzt verstehe ich, worauf Du raus wolltest. Ich wurde mittlerweile auf dem englischen Forum auch auf "Ben's Action Engine" hingewiesen und finde den Ansatz recht interessant, besonders, wenn man das ganze dann noch mit VIs kapselt (um die Queues von den Benutzer-VIs zu verstecken). Allerdings bin ich noch nicht so ganz sicher, ob mir das wirklich gefällt. Ich habe noch den Eindruck, dass das sehr viel Funktionalität an einem Ort vereint, was auch meiner Programmiererfahrung (ok, nicht LabVIEW
) meistens eher von Nachteil ist. Aber ich werde mich damit mal noch beschäftigen.
Allerdings würde ich eher nicht dazu tendieren, das eine "Klasse" zu nennen, denn (zumindest, wie ich das bisher verstehe) es fehlen hier elementare Dinge, die für mich eine Klasse ausmachen, wie Vererbung, Polymorphie, late binding, etc. Für mich ist das eher ein Modul, ein bisschen wie das, was man in C in einer Datei kapselt ohne dass man dafür OOP verwenden würde. Aber letztlich kommt das wahrscheinlich auf die Definition an.
Könnte man ein solches permanent laufendes VI jetzt eigentlich auch reentrant machen und damit z.B. gleichzeitig auf verschiedenen COM-Ports operieren lassen? Ich bin mir noch nicht sicher, ob ich das brauchen würde, aber es klingt verlockend.
Ich habe zu der Implementierung allerdings noch ein paar Fragen:
- Das Beispiel, dass Du gepostet hast führt ja - wenn ich das richtig verstehe - immer nur eine Funktion aus und wartet dann wieder, bis ein neuer Befehl reinkommt, bevor es wieder was tut. Mein Programm müsste ja permanent samplen. Trotzdem müsste das Sampling auf die Daten zugreifen, die auch von den anderen Methoden manipuliert würden. Ich könnte jetzt natürlich immer, wenn kein Befehl anliegt in den Sample-State gehen, aber das hätte den Nachteil, dass das Sampling unterbrochen würde wenn eine andere Funktion länger bräuchte, was auch nicht schön wäre. Kann man das irgendwie geschickt parallelisieren?
- Wo würde man die Parameter- und Result-Queues halten? Wenn ich Deinen Code richtig verstehe, holst Du sie Dir nach Namen, oder?
Hm... ich glaube, ich habe noch mehr, aber die fallen mir grade nicht mehr ein.
Ich werde damit jetzt mal noch ein bisschen rumprobieren, vielleicht aber auch nochmal eine LVOOP oder dqGOOP Version mit Referenzen ausprobieren (für mich ist das halt grundsätzlich der gewohntere Blickwinkel, aber ich lerne auch gerne dazu).
Im Moment habe ich noch nicht wirklich was, das ich mal sinnvoll hochladen könnte. Aber ich habe das noch vor.
Irgendwie ist LabVIEW schon eine recht spannende Sache. Gibt es zu der Sprache eigentlich schon irgendwelche akademischen Abhandlungen, die die Paradigmen mal im Lichte der Informatik betrachten? Mir waren aus dem Studium funktionale Sprachen bekannt (wenn auch mehr theoretisch als praktisch), aber mit Datenflusssprachen bin ich vor LabVIEW noch nie in Berührung bekommen.
Danke nochmal,
Tobias
