Eigenes Package: use vs. GP_Utils(import)

[erwin]

Folgendes scenario:

Code: [Auswählen]

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

[Beta-User]

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...

[erwin]

Hi Beta-User,

Das Argument kann ich nachvollziehen:

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:

Code: [Auswählen]

#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

[Beta-User]

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.

Code: [Auswählen]

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").