Rätselhaftes Überschreiben der fhem.cfg

[Thorsten Pferdekaemper]

eine reorganisation in package wäre eine große und nicht kompatible änderung.

Wieso das denn? Ich rede ja nicht davon, die fhem.pl in ein anderes Package zu verschieben, sondern nur in den Modulen. Es ist mir auch klar, dass man das nicht einfach so für jedes Modul schnell mal ändern kann, aber für neue Module sollte man es "verlangen".

das absichtliches überschreiben lässt sich damit auch nicht verhindern.

Nein, das natürlich nicht.

das versehentliche nur bedingt.

Zumindest das hier beschriebene Problem wäre nicht aufgetreten, oder?

packages für module haben auch noch andere aspekte bzw. nebenwirkungen die man zumindest berücksichtigen müsste.

Welche?
Ich habe das selbst schon so gemacht. Nur die Funktion <module>_Initialize muss man im main-Package lassen, weil sie ansonsten natürlich nicht gefunden wird. Alles weitere kann man in ein eigenes Package legen. Zumindest bei meinem Roomba980-Prototyp funktioniert das.

Gruß,
   Thorsten

[papa]

Eine langfristige Lösung kann eigentlich nur das Unterbinden von ungeprüften Manipulationen der internen Datenstrukturen sein. Das sollte nur über eine entsprechende API möglich sein. Für $init_done könnte das z.B. so aussehen:

• Zugriffsfunktionen implementieren: isInitDone(), setInitDone()
• Zeitfenster zur Migration der Module definieren
• globale Variable $init_done umbenennen und am besten "privat" machen - keine Ahnung, ob das in Perl möglich ist

Die Manipulationsfunktionen könnten dann auch gegebenenfalls eine Prüfung der Argumente vornehmen oder checken, ob eine Manipulation gerade erlaubt ist (Statemachine oder ähnliches Prüfen).

[Thorsten Pferdekaemper]

Das ist jetzt aber wirklich etwas viel Aufwand. ...zumindest wesentlich mehr als meine Idee.
Gruß,
   Thorsten

[Benni]

Das ist jetzt aber wirklich etwas viel Aufwand.

Aber entspricht im wesentlichen auch dem Ansatz, den auch die Funktionen ReadingsVal, AttrVal und InternalVal, sowie die readings.*Update() (und div. andere) zumindest teilweise bereits verfolgen.

Für meinen Geschmack jedenfalls logischer und übersichtlicher, als die Package-Lösung.

[justme1968]

da es niemand von außen setzen soll reicht doch ein isInitDone. setInitDone braucht es garnicht.

das problem ist hier eher das schon alle möglichen module $init_done verwenden und es sich nicht einfach umstellen lässt.

es nützt glaube ich auch nicht wirklich etwas sich an dieser einen variable fest zu beissen. in den ganzen letzen jahren gab es ja scheinbar erst ein mal ein problem damit.

@Thorsten Pferdekaemper: je nach dem wie man genau was in welcher reihenfolge macht führt das verenden von namespaces unter anderem dazu das externe pakete die unter einem namespace geladen werden auch (nur) innerhalb des namespace landen. das gegenseitige abschotten ist zwar gut, aber ich glaube das sie dann auch mehrfach geladen werden. das geht bei modulen wie xml und json schon etwas in den speicher. zumindest auf den ganzen kleinen kisten. auch ist dann z.b. Data::Dumper nicht mehr 'einfach da' sondern muss wenn man man schnell auf der kommandozeile etwas ausgeben will.

d.h. unabhängig davon ob man die änderungen positiv oder negativ bewertet muss man die nebenwirkungen beachten.

[zap]

Ich halte den Vorschlag von papa für den einzig sinnvollen. Oder man lässt alles wie es ist.

Eigentlich hätte man für jede globale Variable in fhem.pl gleich entsprechende Zugriffsfunkionen (is/set/get) zur Verfügung stellen müssen. Aber hätte, hätte, Fahrradkette

Zu spät ist es noch nicht, aber aufwändig:

1. Funktionen bereitstellen
2. Modulautoren bitten, alle Module anzupassen sofern sie eine globale Variable verwenden
3. Ein Prüfscript schreiben, das die Verwendung globaler FHEM Variablen in den Modulen prüft. Falls welche gefunden werden, den Modulautor nochmal anschreiben.
4. Bei Aufnahme neuer Module in SVN prüfen, ob globale Variablen verwendet werden. Eine einfache Prüfung auf $varname sollte genügen.

[viegener]

Mir erscheint es als erster Schritt am einfachsten mal kurz zu listen welche globalen variablen in Modulen (vielleicht auch durch Gruppierung in fhem.pl):
- gelesen werden können --> sprich z.B. init_done (gibt es wirklich szenarien in denen ein normales Modul das setzen sollte )
- verändert werden dürfen --> z.B: in gewissen Grenzen %attr etc
- nicht angefasst werden sollten --> subject to change without notice

[Thorsten Pferdekaemper]

@Thorsten Pferdekaemper: je nach dem wie man genau was in welcher reihenfolge macht führt das verenden von namespaces unter anderem dazu das externe pakete die unter einem namespace geladen werden auch (nur) innerhalb des namespace landen. das gegenseitige abschotten ist zwar gut, aber ich glaube das sie dann auch mehrfach geladen werden. das geht bei modulen wie xml und json schon etwas in den speicher. zumindest auf den ganzen kleinen kisten. auch ist dann z.b. Data::Dumper nicht mehr 'einfach da' sondern muss wenn man man schnell auf der kommandozeile etwas ausgeben will.

Soweit ich das verstehe, werden zumindest Module, die man mit require lädt, nur einmal geladen. Das mit dem mehrfach "Laden" betrifft das import (implizit durch use). Dadurch kommen die vom Modul exportierten Symbole in den jeweiligen Namespace. Das dürfte aber nicht viel Speicherplatz kosten. Data::Dumper wäre dann trotzdem noch da, so lange irgend jemand das "require"t. Nur wenn ein Modul etwas "use"t, dann müsste man, wenn man die entsprechende Funktion/Variable von woanders verwenden will, sie entweder dort auch importieren oder halt "<Modul>::" vorne dran setzen.
Ausprobiert habe ich das alles nicht...

d.h. unabhängig davon ob man die änderungen positiv oder negativ bewertet muss man die nebenwirkungen beachten.

Da stimme ich voll zu.

Das mit den Zugriffsfunktionen hilft übrigens nichts, solange alles im package main ist. ...denn dann kann es immer noch relativ leicht passieren, dass ein Modul "aus versehen" auf eine globale Variable eines anderen Moduls (oder fhem.pl) zugreift.

Gruß,
   Thorsten

[justme1968]

wie gesagt ist es ein abwägen. wenn man die namespace vorteile auch für pakete möchte um z.b. konflikte mit unterschiedlichen parametern zu vermeiden (ist z.b. bei xml schon mehrfach vorgekommen) kostet es den speicher. und das wäre ein anwendungsfall der tatsächlich schon ein paar mal vorgekommen ist.

[betateilchen]

Die ganze Diskussion über is/set/get<globaleVariable> ist doch müssig, solange selbst in neuen Modulen (beispielsweise) immer noch $hash->{STATE} von den Modulautoren hart beschrieben wird anstatt das entsprechende reading state zu verwenden und dem Anwender die Freiheit zu lassen, STATE nach seinen Wünschen zu formatieren.

[Prof. Dr. Peter Henning]

Auch das ließe sich mit einer Konformitätsprüfung in einen Warnhinweis überführen.

LG

pah

[justme1968]

die frage ist ob uns eine warnung bzw. prüfung beim einchecken reicht oder ob es nicht besser ist zu versuchen die 'altlasten' aktiv anzugehen und alle module aktiv anzupassen.

ersteres ist zwar sehr viel weniger aufwand, der effekt hält sich aber in grenzen und 'alte' module veralten immer mehr.

letzteres ist deutlich aufwändiger aber der code bleibt längerfristig auf einem aktuellen stand und neuerungen lassen sich besser einführen.

[Prof. Dr. Peter Henning]

Einverstanden. Das wäre also eine einfache Routine zum Codecheck aller Module - mit kurzem Elektroschock für die Maintainer, ihren Code gefälligst anzupassen.

LG

pah