Verhalten Hash wenn nicht vorhandener Schlüssel abgefragt wird

Begonnen von DS_Starter, 21 März 2021, 17:11:07

Vorheriges Thema - Nächstes Thema

DS_Starter

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
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Sidey

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

DS_Starter

Danke Sidey  :)
Trotzdem finde ich es ein unlogisches Verhalten wenn der Key in dem Fall einfach angelegt wird.
Aber gut zu wissen.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Wzut

IMHO hatte da Rudi vor langer Zeit mal einen schönen Beitrag mit guter Erklärung (was man darf und was nicht)  dazu gepostet.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

rudolfkoenig

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.

DS_Starter

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.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter