Autor Thema: Eigenes Package: use vs. GP_Utils(import)  (Gelesen 581 mal)

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 766
Eigenes Package: use vs. GP_Utils(import)
« am: 23 Juli 2022, 11:12:53 »
Folgendes scenario:
package abcdefg; ## no critic 'package'

use strict;
use warnings;
use Encode qw(encode decode);
use Time::HiRes qw(gettimeofday);
use Scalar::Util qw(looks_like_number);
use GPUtils qw(GP_Import GP_Export);

BEGIN {
    # Import from main context
    GP_Import(
        qw(......) ) };
Die Frage: ist es aus memory/performance Überlegungen besser
1) use zu verwenden, wenn die betreffenden Module/Funktionen ohnehin schon durch fhem.pl geladen werden? trifft in diesem Bsp. auf Encode,Time::Hires, Scalar::Util zu!
2) use nicht zu verwenden, und die benötigten funktionen in GP_Import zu definieren? (implizit z.b: main:encode zu verwenden)

In Variante 2 ist das Risiko, falls fhem.pl die Module in Zukunft nicht lädt, das FHEM insgesamt stirbt....
l.g.erwin

FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 00_KNXIO.pm 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18998
Antw:Eigenes Package: use vs. GP_Utils(import)
« Antwort #1 am: 23 Juli 2022, 11:54:50 »
Hmm, lese mal mit...

Bisher hatte ich alles auf Variante 1 umgestellt. Meine (möglicherweise falschen!) Überlegungen:
- eigentlich will ich "wissen", wo was herkommt, wenn es nicht originär aus dem main-Kontext kommt (also insbesondere fhem.pl, 99_Utils.pm, DevIo);
- GP_Utils ist eigentlich ein "matschiger Notbehelf", weil es (afaik im Unterschied zu use-Anweisungen) in beide Richtungen wirkt (leider habe ich mir keinen Link auf die Fundstelle gemerkt);
- nach meinem Verständnis sind GP_Utils-Imports eigentlich auch nur (indirekte) Referenzierungen, und von daher spart man sich möglicherweise eine "Umleitung", indem man direkt die Referenz auf was sowieso geladenes legt (?).

OT:
- GP_Export verwende ich dagegen gar nicht (ersetzt durch goto-Anweisungen).
- encode/decode ist in den meisten meiner Module überflüssig geworden, seit JSON->new->decode etc. decode_json verdrängt hat...
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 766
Antw:Eigenes Package: use vs. GP_Utils(import)
« Antwort #2 am: 24 Juli 2022, 13:21:56 »
Hi Beta-User,

Das Argument kann ich nachvollziehen:
Zitat
eigentlich will ich "wissen", wo was herkommt, wenn es nicht originär aus dem main-Kontext kommt...
speziell wenn man die Funktionen explizit angibt!
Argument:  Les-/Wartbar-keit des codes! Vielleicht hätte ich meine Frage "offener" formulieren sollen.

OT: encode/decode: brauch ich dzt. wg eines devices, das 'iso-8859-1' liefert/erwartet. (ohne json...)
Das hab ich dzt. so realisiert:
#FHEM->IO
$val = encode('iso-8859-1', decode('utf8', $value)); #convert to latin-1
#IO->FHEM
$val = encode ('utf8', decode('iso-8859-1',$state))
$val =~ s/[\x00-\x1F]+//gx; # remove non printable chars for reading-value!
das wird  via DevIo gesendet/empfangen...
... funktioniert dzt. prima, ob das Probleme macht, falls jemand auf unicode umstellt, ist mir noch nicht klar!
und ich hab auch schon entdeckt dass es in fhem.pl ein: latin1ToUtf8 / utf8ToLatin1 gibt...
l.g. erwin
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 00_KNXIO.pm 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18998
Antw:Eigenes Package: use vs. GP_Utils(import)
« Antwort #3 am: 24 Juli 2022, 14:01:52 »
speziell wenn man die Funktionen explizit angibt!
Na ja, das kann man (?) auch, wenn man GP_Utils verwendet. Das sollte übrigens afai remember auch "maulen", wenn eine erwünschte Funktion nicht verfügbar ist. Das bringt mich aber auf ein anderes Problem mit GP_Utils: Man weiß nie so richtig, WARUM eine Funktion in main verfügbar ist - es könnte auch "irgendwas" sein, das "irgendjemand" (aus welchem Grund auch immer "zufällig" (schon!) in den main-Kontext importiert hat => anderes System, andere Reigenfolge, ggf. bestimmte nicht verwendete Module => beim Kunden stirbt das Produkt... Unschön.

Von daher würde ich das jetzt eher in die Richtung sehen, dass "sauberes" Coding klare Referenzierungen braucht.

OT: encode/decode:Klar, wenn man was bestimmtes braucht, spricht nichts dagegen (wobei es in der Regel schlau sein dürfte, die im Kernel (fhem.pl) enthaltenen Funktionen zu nehmen, wenn sie tun was benötigt wird. Ist tendenziell weniger stressbehaftet, und es entspicht afaik den Empfehlungen von Rudi (sinngemäß: "der Maintainer muss wissen, was die Gegenstelle liefert, und das dann an allen Schnittstellen zwischen innen und außen sauber konvertieren").
Server: HP-T620@Debian 11, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

 

decade-submarginal