Smartmatch und andere experimentelle Perl-Features

[Beta-User]

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.

[Dr. Boris Neubert]

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?

[rudolfkoenig]

Liest Rudi hier mit?

Ja, ich warte nur die Ende der Diskussion und eine klare Ansage ab

[erwin]

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

[Dr. Boris Neubert]

Gibts Nachteile/Pitfalls wenn man Zahlen mit eq vergleicht?

Ich habe ChatGPT gefragt. Hier der relevante Schnipsel aus der Antwort:

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

[betateilchen]

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.

[Dr. Boris Neubert]

https://forum.fhem.de/index.php?topic=139688

Code Auswählen Erweitern

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

[rudolfkoenig]

Habs eingecheckt, allerdings mit etwas Bauchschmerzen wegen

Code Auswählen Erweitern

use List::Util qw(any);

[betateilchen]

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!

[rudolfkoenig]

Erledigt.

[betateilchen]

Erledigt.

Danke.

mit etwas Bauchschmerzen wegen

Code Auswählen Erweitern

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.

[Beta-User]

Habs eingecheckt, allerdings mit etwas Bauchschmerzen wegen

Code Auswählen Erweitern

use List::Util qw(any);

Sollte kein allzu großes Problem mehr sein, jedenfalls wenn ich das richtig zusammengefieselt habe:

Code Auswählen Erweitern

{ Module::CoreList->first_release('List::Util', 1.33) }=>
5.019005

[Beta-User]

Nachdem keine bessere Lösung vorgebracht wurde schlage ich nunmehr wie Udo vor, beide Funktionen in fhem.pl zu implementieren.

Nimmst du die bitte aus Calendar wieder raus (https://forum.fhem.de/index.php?topic=139979.0)?

[Dr. Boris Neubert]

Nachdem keine bessere Lösung vorgebracht wurde schlage ich nunmehr wie Udo vor, beide Funktionen in fhem.pl zu implementieren.

Nimmst du die bitte aus Calendar wieder raus (https://forum.fhem.de/index.php?topic=139979.0)?

getan