Zitat von: rudolfkoenig am 04 April 2024, 23:37:17Off-Topic: mein perl 5.38 beschwert sich: Smartmatch is deprecated at FHEM/TimeSeries.pm line 113.
Auch offtopic: bei switch ist es ähnlich. Diese Experimente sollen wohl ab 5.42 komplett entfernt werden.
Ich habe den Beitrag von Udo abgeteilt und hierher gestellt, damit wir uns mit dem Schicksal von Smartmatch, given, when, switch und was weiß ich noch für experimentellen Features von Perl befassen und für den FHEM-Code darauf reagieren.
Interessant (habe mich aber nicht weiter damit auseinandergesetzt): Perl 5.20 and the fate of smart matching and given-when (https://stackoverflow.com/questions/16927024/perl-5-20-and-the-fate-of-smart-matching-and-given-when).
Ich liebe ~~ für die Prüfung, ob ein Element in einem Array steht.
Na toll. Da darf ich ja dann einiges umschreiben.
Zitat von: CoolTux am 05 April 2024, 13:30:07Na toll. Da darf ich ja dann einiges umschreiben.
So neu ist das ja eigentlich sich nicht... In der Perl-Ecke gibt es dazu einige "Warnungen" - die sind mehrere Jahre alt...
Smartmatch z.B. müßte relativ einfach mit einem grep zu fixen sein. (Muss ggf. mal suchen.)
Zitat von: CoolTux am 05 April 2024, 13:30:07Na toll. Da darf ich ja dann einiges umschreiben.
Zitat von: Beta-User am 05 April 2024, 13:37:13So neu ist das ja eigentlich sich nicht...
Stimmt, die smartmatch Problematik ist seit 5.18 bekannt und deshalb sind die darauf basierenden features (z.B. switch/given) seither als "experimental" gekennzeichnet. Dass die irgendwann wegfallen, ist nicht überraschend, inzwischen weiß man halt auch, wann das passieren wird.
Meine drei aktiven Module, die davon betroffen sind, habe ich heute umgebaut. Dabei habe ich given/when einfach durch if/elsif/else ersetzt. Das war die einfachste Lösung, die versionsunabhängig und ohne weitere Modul-Abhängigkeiten funktioniert.
Zitat von: Dr. Boris Neubert am 05 April 2024, 09:24:15Ich liebe ~~ für die Prüfung, ob ein Element in einem Array steht.
Zitat von: Beta-User am 05 April 2024, 13:37:13Smartmatch z.B. müßte relativ einfach mit einem grep zu fixen sein.
if (grep(regex, @array)) {}
Zitat von: betateilchen am 05 April 2024, 13:53:01if grep(regex, @array) {}
Meine mich erinnern zu können, dass das perlcritics in dieser Fassung nicht optimal findet und die block-Variante vorschlägt. Mobil, ungetestet so:
if (grep m{regex} @array) {}
ja, ich hatte auf die Schnelle beim Tippen die Klammern vergessen.
Ansonsten bleibe ich aber bei dieser Variante:
if (grep(regex, @array)) {}
Hatte nicht behauptet, dass es in der Komma-separierten Variante nicht funktioniert.
Wollte nur anregen, bei einer Überarbeitung der Module ggf. schlicht das online-tool oä. zu nutzen und bei der Gelegenheit gleich die (afair) "bessere" Variante zu wählen. That's all...
Hier noch ein (funktionierendes und hoffentlich verständliches) Beispiel, wie das z.B. in "98_monitoring.pm" nach der perlcritic-Optimierung aussieht (unter Ignorierung der "postfix-if"-critic...):
return if @blacklist && grep { m{\A${name}\z}x } @blacklist;
Zitat von: Beta-User am 05 April 2024, 15:23:38Hier noch ein ... Beispiel, wie das z.B. in "98_monitoring.pm" nach der perlcritic-Optimierung aussieht (unter Ignorierung der "postfix-if"-critic...)
Entschuldigung, aber das ist doch Käse.
Entweder, Du willst es (im Sinne von perlcritic) richtig machen, dann mach es aber auch komplett richtig.
Aber doch bitte nicht den einen (perlcritic)-Mangel beseitigen und den anderen bewusst ignorieren.
Zitat von: betateilchen am 05 April 2024, 15:47:41Entweder, Du willst es (im Sinne von perlcritic) richtig machen, dann mach es aber auch komplett richtig.
Aber doch bitte nicht den einen (perlcritic)-Mangel beseitigen und den anderen bewusst ignorieren.
Schön, dass du das highlightest :) .
Auch Perlcritic kennt mehrere Stufen, und macht Unterschiede. Das "grep"-Thema liegt (aus dem Kopf) auf Level 4, postfix-if dürfte "cruel" sein.
In der Regel würde ich Level 4+5 beseitigen wollen, ausgenommen manche Dinge, die im FHEM-Kontext wenig sinnvoll sind oder im konkreten Fall einfach überzogen, bei Level 3 kann man vermutlich so oder so votieren.
"Meine" Codes laufen (mit wenigen Pflastern) in der Regel bei bis Level-3-Checks (einschließlich) ohne Meckern durch, und die Dinge, die ich über diesen Weg gefunden hatte, waren praktisch alle ziemlich valide.
Bei postfix-if geht es eigentlich v.a. um Lesbarkeit, und wenn da vorne ein "return" steht, macht mein Editor ein schönes Syntax-highlighting und es ist direkt sichtbar, dass hier eine "Ausgangstür" ist - Ziel (anders) voll erreicht. Darf ich ja entscheiden...
https://forum.fhem.de/index.php?topic=139688
#####################################
#
# smartmatch replacement
#
#####################################
# use contains_<type>($scalar, @array) instead of $scalar ~~ @array
# requires List:Util
# see https://www.perlmonks.org/?node_id=1067462
sub contains_numeric($@) {
my ($scalar, @array) = @_;
return any { $_ == $scalar } @array;
}
sub contains_string($@) {
my ($scalar, @array) = @_;
return any { $_ eq $scalar } @array;
}
Hallo,
möchte dafür plädieren contains_numeric und contains_string in die 99_Utils zu übernehmen.
Grüße Jörg
Frage dazu:
Bringt die Unterscheidung in "numeric" und "string" irgend einen (performance-) Vorteil?
Bei "numeric" besteht sonst immer das Riskio, dass jemand gemischte Daten reinwirft (also kein rein numerisches Vergleichsarray) und man am Ende dann eine Ladung Fehlermeldungen hat...
Zitat von: Beta-User am 01 November 2024, 17:28:32Bringt die Unterscheidung in "numeric" und "string" irgend einen (performance-) Vorteil?
Es ist die Frage, welcher Vergleichsoperator ausgewählt werden soll, == oder eq.
Die Performance kommt von any statt grep.
any ist einleuchtend.
eq klappt halt auch mit Zahlen, aber == wirft einen Fehler bei jedem nicht-numerischen Element im Array.
Daher die Frage, ob nicht eine Funktion (mit eq) ausreichend wäre.
Die Funktion wäre ja dann contains_string()
An sich fände ich es gut, wenn beide Funktionen oder was noch besseres nach 99_Utils.pm oder nach fhem.pl käme. Liest Rudi hier mit?
ZitatLiest Rudi hier mit?
Ja, ich warte nur die Ende der Diskussion und eine klare Ansage ab :)
Nachdem any nur ein true/false als Resultat liefert, wäre ich für "eq" - und nur eine function - am besten in fhem.pl
Gibts Nachteile/Pitfalls wenn man Zahlen mit eq vergleicht?
l.g. erwin
Zitat von: erwin am 10 November 2024, 19:18:46Gibts Nachteile/Pitfalls wenn man Zahlen mit eq vergleicht?
Ich habe ChatGPT gefragt. Hier der relevante Schnipsel aus der Antwort:
Zitat... kann unerwartetes Verhalten verursachen, weil eq die Werte als Strings interpretiert. In den meisten Fällen funktioniert es zufällig, wenn die Zahlen ähnlich formatiert sind, aber sobald z.B. führende Nullen oder unterschiedliche Formate vorhanden sind, könnte das Ergebnis falsch sein.
Bei einer Abstimmung wäre ich auch dafür, BEIDE Funktionen zu implementieren. Und zwar sicherheitshalber in der fhem.pl, denn es gibt doch den einen oder anderen user, der seine 99_Utils.pm verhunzt.
Als Entwickler sollte man sich aber bei solchen grundlegenden Funktionen darauf verlassen können, dass sie auch wirklich vorhanden sind.
Es wird nach der Umstellung vermutlich ohnehin den einen oder anderen Supportfall geben, wenn Anwender ihr update nur unvollständig ausführen, weil sie beispielsweise mit exclude_from_update arbeiten. Aber man kann und sollte nicht jede Dummheit abfangen.
Zitat von: Dr. Boris Neubert am 01 November 2024, 14:29:00https://forum.fhem.de/index.php?topic=139688 (https://forum.fhem.de/index.php?topic=139688)
#####################################
#
# smartmatch replacement
#
#####################################
# use contains_<type>($scalar, @array) instead of $scalar ~~ @array
# requires List:Util
# see https://www.perlmonks.org/?node_id=1067462
sub contains_numeric($@) {
my ($scalar, @array) = @_;
return any { $_ == $scalar } @array;
}
sub contains_string($@) {
my ($scalar, @array) = @_;
return any { $_ eq $scalar } @array;
}
Nachdem keine bessere Lösung vorgebracht wurde schlage ich nunmehr wie Udo vor, beide Funktionen in fhem.pl zu implementieren.
Habs eingecheckt, allerdings mit etwas Bauchschmerzen wegen
use List::Util qw(any);
Hallo Rudi,
würdest Du bitte die beiden neuen Funktionen noch in die Liste der "Forward declarations" am Anfang der fhem.pl aufnehmen? Diese Liste benutze ich gerne beim Suchen von passenden Funktionen :)
Danke!
Erledigt.
Zitat von: rudolfkoenig am 01 Dezember 2024, 11:32:02Erledigt.
Danke.
Zitat von: rudolfkoenig am 30 November 2024, 19:55:15mit etwas Bauchschmerzen wegen
use List::Util qw(any);
Inzwischen habe ich das Paket libscalar-list-utils-perl in die dependencies für das Debian-Paket von FHEM aufgenommen, damit sollte es zumindest bei Neuinstallation unter Debian und Derivaten keine Probleme geben.
Zitat von: rudolfkoenig am 30 November 2024, 19:55:15Habs eingecheckt, allerdings mit etwas Bauchschmerzen wegen
use List::Util qw(any);
Sollte kein allzu großes Problem mehr sein, jedenfalls wenn ich das richtig zusammengefieselt habe:
{ Module::CoreList->first_release('List::Util', 1.33) }=>
5.019005
Zitat von: Dr. Boris Neubert am 30 November 2024, 12:50:00Nachdem keine bessere Lösung vorgebracht wurde schlage ich nunmehr wie Udo vor, beide Funktionen in fhem.pl (https://fhem.pl/) zu implementieren.
Nimmst du die bitte aus Calendar wieder raus (https://forum.fhem.de/index.php?topic=139979.0)?
Zitat von: Beta-User am 04 Dezember 2024, 10:04:51Zitat von: Dr. Boris Neubert am 30 November 2024, 12:50:00Nachdem keine bessere Lösung vorgebracht wurde schlage ich nunmehr wie Udo vor, beide Funktionen in fhem.pl (https://fhem.pl/) zu implementieren.
Nimmst du die bitte aus Calendar wieder raus (https://forum.fhem.de/index.php?topic=139979.0)?
getan