Es ist mir ein bislang zumindest mir nicht vordergründig bewußtes Verhalten bei Hashes aufgefallen.
Wenn man bei einem Hash einen nicht vorhandenen Schlüsselwert abfragt, wird dieser Schlüssel leer angelegt.
Ein kleines Beispiel zeigt was ich meine:
my %pv;
$pv{sl}{k00}{val} = 0;
$pv{sl}{k01}{val} = 1;
my $t = $pv{sl}{k02}{val} // 0;
Log3 ($name, 1, "$name - Test: ".Dumper %pv);
Wie ihr seht soll val des Schlüssels k02 einer Variablen zugewiesen werden.
Den Key k02 gibt es aber in dem Hash nicht.
Lässt man sich nach der Routine den Hash mit Dumper ausgeben ist zu sehen, dass der Key k02 leer angelegt wurde:
2021.03.21 16:51:20.262 1: SolCast - Test: 'sl'
{
'k02' => {},
'k00' => {
'val' => 0
},
'k01' => {
'val' => 1
}
}
Ich finde das Verhalten etwas merkwürdig, da ja kein Zuweisungsbefehl vorhanden ist.
LG,
Heiko
Das ist so dokumentiert.
Als Lösung gibt es die Funktion exists:
https://perldoc.perl.org/functions/exists
Danke Sidey :)
Trotzdem finde ich es ein unlogisches Verhalten wenn der Key in dem Fall einfach angelegt wird.
Aber gut zu wissen.
IMHO hatte da Rudi vor langer Zeit mal einen schönen Beitrag mit guter Erklärung (was man darf und was nicht) dazu gepostet.
Das ist der Grund, warum
- man ReadingsVal, AttrVal etc verwenden sollte: diese Funktionen pruefen vorher, ob ueberhaupt ein $defs/etc Eintrag vorhanden ist.
- wenn man das nicht macht, in $defs unfertige Instanzen ohne TYPE angelegt werden, was man wiederum an vielen Stellen nur wegen solchen Unfaellen pruefen muss.
Auf der anderen Seite wird dadurch das Anlegen tiefer Strukturen deutlich vereinfacht und besser lesbar bzw. wartbar.
Hallo Rudi, ja für die FHEM Standard-Hashes verwende ich die subs. Ich bin nur bei der Arbeit mit eigenen Hashes darauf gestoßen und konnte mir lange nicht erklären wieso diese leeren Keys angelegt werden bis ich auf diesen Zusammenhang stieß.
Jetzt baue ich mir für solche Abfragen eine eigene sub für diese Hashes nach dem Vorbild von ReadingsVal.