Autor Thema: Timerverwaltung bei vorab unbekannter Timerzahl- best practice?  (Gelesen 1349 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14272
  • "Developer"?!? Meistens doch eher "User"
Antw:Timerverwaltung bei vorab unbekannter Timerzahl- best practice?
« Antwort #30 am: 04 Mai 2021, 10:50:35 »
Nicht ganz. Wenn man eine schwache Referenz einer normalen zuweist, dann wird daraus wieder eine starke. D.h. $p->{instance} ist eine normale Referenz.
So geht es richtig:
Danke für den Schnipsel, das hilft mir jetzt wirklich weiter!

Zitat
Ich war davon ausgegangen, dass irgendwo sowas steht wie
$hash->{TIMER} = $p;
Ja, klar, sonst kann man die Anforderung nicht umsetzen, die vielleicht jetzt nochmal präziser formuliert so lauten: Es sollen zwei Variablen "irgendwie" an InternalTimer übergeben werden, von denen eine eine eindeutige Zuordnung zu einer bestimmten Modulinstanz ermöglichen, _und_ es soll die Möglichkeit geben, genau diesen Timer wieder zu löschen bzw. ggf. zu erneuern.

Bzgl. RHASSPY war ich grade am Überlegen, ob der Aufwand lohnt, weil kaum jemand häufig sein Device umbenennen wird und es sowieso erforderlich ist, Daten unter der SessionId irgendwo zwischenzuspeichern. Von daher könnte man auch die Namensvariante relativ unproblematisch verwenden und dann eben "nichts" machen, wenn keine Sitzungsdaten vorhanden sind bzw. den Timer unter dem Namen versuchen zu löschen. Geht das (wg. Umbenennung) schief, passiert nichts schlimmes. Das ist bei den anderen Modulen etwas anders, weil da teilweise zyklische Timer dabei sind, die zu einer Reinitialisierung führen => das Modul bleibt schlimmstenfalls stehen. Andererseits sollten sich diese Timer mit schlichtem $hash als Argument anlegen lassen. (Und die Timerverwaltung in Twilight und WeekdayTimer gefällt mir eh' nicht mehr, bei Gelegenheit baue ich das eventuell in eine Art "asyncQueue" um und hinterlege intern, was der nächste Schritt ist.

Werde jetzt jedenfalls im ersten Schritt dann nochmal den vorhandenen Code mit "weaken" aufbohren, und dann mal schauen...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14272
  • "Developer"?!? Meistens doch eher "User"
Antw:Timerverwaltung bei vorab unbekannter Timerzahl- best practice?
« Antwort #31 am: 04 Mai 2021, 12:43:36 »
Anbei dann erst mal der Code als "lib".

Bin nach der ganzen Diskussion jetzt unschlüssig, ob es sinnvoll ist, den wirklich als lib allg. bereitzustellen, aber zumindest die drei Module gedenke ich jetzt erst mal nach diesem Muster updaten.
Also falls da jetzt doch noch ein "unentdeckter Haken" sein sollte, wäre ich für zielführende Hinweise dankbar.

Das braucht in dieser Form keine RenameFn.

Was der Timer bei Ablauf an Argumenten übergibt, wird in etwa so ausgepackt (die Funktionsnamen in der lib sind etwas anders/gekürzt):
sub RHASSPY_DialogTimeout {
    my $fnHash = shift // return;
    my $hash = $fnHash->{HASH} // $fnHash;
    return if !defined $hash;

    my $identiy = $fnHash->{MODIFIER};

    my $data     = shift // $hash->{helper}{'.delayed'}->{$identiy};
    delete $hash->{helper}{'.delayed'}{$identiy};
    deleteSingleRegisteredInternalTimer($identiy, $hash);

Timer werden so gesetzt bzw. ggf. erneuert:
sub setDialogTimeout {
    my $hash     = shift // return;
    my $data     = shift // return; # $hash->{helper}{'.delayed'};
    my $timeout  = shift;
    my $response = shift;
    my $toEnable = shift // [qw(ConfirmAction CancelAction)];

    my $siteId = $data->{siteId};
    $data->{'.ENABLED'} = $toEnable;
    my $identiy = qq($data->{sessionId});

    $response = $hash->{helper}{lng}->{responses}->{DefaultConfirmationReceived} if $response eq 'default';
    $hash->{helper}{'.delayed'}{$identiy} = $data;

    resetRegisteredInternalTimer( $identiy, time + $timeout, \&RHASSPY_DialogTimeout, $hash, 0);
    #InternalTimer(time + $timeout, \&RHASSPY_DialogTimeout, $hash, 0);

#[...]
    return; # $toTrigger;
}

und die UndefFn sieht so aus (unterstellt, es gibt auch noch "normale" Timer):
sub Undefine {
    my $hash = shift // return;

    deleteAllRegisteredInternalTimer($hash);
    RemoveInternalTimer($hash);

    return;
}
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6221
  • Finger weg von der fhem.cfg
Antw:Timerverwaltung bei vorab unbekannter Timerzahl- best practice?
« Antwort #32 am: 04 Mai 2021, 13:51:42 »
Hi,
gibt es eigentlich einen Grund, warum überall die Deklaration der Funktionsparameter fehlt? Außerdem werden die Parameter überall per "shift" gefüllt. Das ist alles ziemlich übel unübersichtlich.
Gruß,
   Thorsten
FUIP

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 26781
Antw:Timerverwaltung bei vorab unbekannter Timerzahl- best practice?
« Antwort #33 am: 04 Mai 2021, 14:02:11 »
Hi,
gibt es eigentlich einen Grund, warum überall die Deklaration der Funktionsparameter fehlt? Außerdem werden die Parameter überall per "shift" gefüllt. Das ist alles ziemlich übel unübersichtlich.
Gruß,
   Thorsten

https://en.wikipedia.org/wiki/Perl_Best_Practices

https://forum.fhem.de/index.php/topic,109526.0.html
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14272
  • "Developer"?!? Meistens doch eher "User"
Antw:Timerverwaltung bei vorab unbekannter Timerzahl- best practice?
« Antwort #34 am: 04 Mai 2021, 14:04:02 »
Hi,
gibt es eigentlich einen Grund, warum überall die Deklaration der Funktionsparameter fehlt? Außerdem werden die Parameter überall per "shift" gefüllt. Das ist alles ziemlich übel unübersichtlich.
Gruß,
   Thorsten
Prototypen (das ist es doch das, was du mit "Deklaration der Funktionsparameter" meinst, oder?) verwende ich seit einiger Zeit nicht mehr. Ist am Anfang etwas gewöhnungsbedürftig, entspricht aber dem, was als "Perl Best Practice" propagiert wird (siehe die Links von CoolTux).

Die Übergabe mit shift hat zwei Vorteile: Zum einen kann man im Fehlerfall bzw. bei nicht genügender Parameter-Übergabe mit "carp" eine gezieltere Fehlermeldung als "prototype mismatch" ausgeben (siehe die "lib"-Variante), zum anderen ist es direkt in der einleitenden Übersicht der Parameter klar erkannbar, was optional ist, was zwingend und man kann auch gleich Ersatzwerte zuweisen.

Ich finde das daher nicht mehr "übel unübersichtlich", sondern hilfreich (selbst wenn es ab ca. 3 Parametern etwas langsamer ist) ;D .
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6221
  • Finger weg von der fhem.cfg
Antw:Timerverwaltung bei vorab unbekannter Timerzahl- best practice?
« Antwort #35 am: 04 Mai 2021, 14:44:59 »
https://en.wikipedia.org/wiki/Perl_Best_Practices
Nein, ich werde jetzt nicht das Buch kaufen...

Zitat
https://forum.fhem.de/index.php/topic,109526.0.html
Ach das. Ich dachte, dass sich das geben wird, weil offensichtlich falsch. Er zeigt in dem Beitrag ja gerade, dass er es nicht verstanden hat. Die weitere Argumentation ist dann "weil ich es nicht verstanden habe (also etwas anderes erwarte) muss es weg". Witzig, dass man der Argumentation irgendeine Bedeutung beimisst.
Ich habe noch ein bisschen rumgesucht, ob ich noch bessere Argumente finde. Da war noch was in dem Stil "es wird nicht überprüft und könnte falsch, also kann es weg". Mit der Argumentation dürfte man auch keine Kommentare mehr ins Coding schreiben.

Die Übergabe mit shift hat zwei Vorteile: Zum einen kann man im Fehlerfall bzw. bei nicht genügender Parameter-Übergabe mit "carp" eine gezieltere Fehlermeldung als "prototype mismatch" ausgeben
Das ist aber ein Argument gegen die Prototypen und nicht für das "shift", oder? Dafür ist das Argument tatsächlich valide, würde mir aber nicht ausreichen, um die Unübersichtlichkeit zu kompensieren. Mir ist klares Coding wichtiger als die perfekte Fehlermeldung bei Programmierfehlern. Wenn man den "prototype mismatch" bekommt, dann sieht man sowieso sofort, woran es hängt.

Zitat
(siehe die "lib"-Variante), zum anderen ist es direkt in der einleitenden Übersicht der Parameter klar erkannbar, was optional ist, was zwingend
Das sehe ich anders, insbesondere, wenn dann plötzlich irgendwo weiter unten mal wieder ein "shift" erscheint. Worauf bezieht sich das dann?
...und wodurch sieht man, was optional ist und was zwingend? Das würde man bei der ($$;$$)-Notation sofort sehen.
    my ($hash, $data, $timeout, $response, $toEnable ) = @_
Das macht meiner Meinung nach viel klarer, dass das eigentlich die Parameter sind, und darauf kommt es mir an.

...aber vielleicht ist das auch alles ein bisschen Geschmacksache. Mir gefällt der Stil nicht, aber ich will auch meinen Stil niemandem aufzwingen.

Gruß,
   Thorsten
FUIP
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14272
  • "Developer"?!? Meistens doch eher "User"
Antw:Timerverwaltung bei vorab unbekannter Timerzahl- best practice?
« Antwort #36 am: 04 Mai 2021, 15:21:52 »
Nein, ich werde jetzt nicht das Buch kaufen...
Muss man auch nicht. Man bekommt dieselben Inhalte auch vercoded, z.B. unter http://perlcritic.com/ und kann sich dann da über das jeweilige ? beim "Kritikpunkt" anzeigen lassen, wie man den Punkt ggf. alternativ vercoden könnte.

Zitat
Ach das. Ich dachte, dass sich das geben wird, weil offensichtlich falsch. Er zeigt in dem Beitrag ja gerade, dass er es nicht verstanden hat. Die weitere Argumentation ist dann "weil ich es nicht verstanden habe (also etwas anderes erwarte) muss es weg". Witzig, dass man der Argumentation irgendeine Bedeutung beimisst.
Man mag über Stilfragen hinsichtlich des gegenseitigen Umgangs streiten, aber afaik ist die Kritik an sich nicht unberechtigt. Ich habe jedenfalls in den übernommenen Modulen einige Beispiele gefunden, bei denen ich _glaube_, dass der ursprüngliche Autor nicht mehr wußte, welche Art der Parameter er wollte und welcher Datentyp überhaupt erwartet wird.

Zitat
Das ist aber ein Argument gegen die Prototypen und nicht für das "shift", oder?
Jein. Es ist eigentlich eher für "shift", weil das auch dann noch gilt, wenn man mit Prototypen arbeitet

Zitat
Das sehe ich anders, insbesondere, wenn dann plötzlich irgendwo weiter unten mal wieder ein "shift" erscheint.
Das shift ist an der Stelle nicht mehr unbedingt glücklich, vermutlich wäre es in der Tat besser, das shift gleich zu machen und hinten dann eben eine deutlich längere Prüfung der Randbedingungen vorzunehmen. So ist es eben "direkter" notiert...

Zitat
...und wodurch sieht man, was optional ist und was zwingend? Das würde man bei der ($$;$$)-Notation sofort sehen.
Das stimmt nun wieder nur bedingt. Es gibt einige Funktionen in FHEM, bei denen der Prototype mit ($$$$) angegeben ist, aber nur der erste Parameter muss wirklich "content" haben, die anderen können "undef" sein, und es gibt auch Fälle, in denen irgendwas zwischendurch "undef" sein kann, aber hinten was gebraucht wird und Fälle, in denen 2 aus 4 genügen. Alle diese Art Abhängigkeiten bekommt man nicht mit, wenn man die vermeintlich übersichtliche Variante
    my ($hash, $data, $timeout, $response, $toEnable ) = @_
wählt.

"Ganz übel" wird es, wenn es möglich ist, an eine Funktion entweder einen SCALAR oder was anderes (z.B. ein ARRAY) als Argument zu übergeben. Ich nutze das teils, um die weitere Funktionsweise der jeweiligen Funktion umzuschalten.
Bei Verwendung von Prototypen wäre sowas wohl (prinzipbedingt) "verboten" (ob das "guter Stil" ist, ist eine andere Frage, aber da lasse ich mich ggf. gerne beraten, wie es besser geht).

Zitat
Mir ist klares Coding wichtiger als die perfekte Fehlermeldung bei Programmierfehlern. Wenn man den "prototype mismatch" bekommt, dann sieht man sowieso sofort, woran es hängt.
Mit shift kannst du jedenfalls z.B. auch direkt hinter die jeweilige Zeile einen Kommentar schreiben, welches Argument du erwartest bzw. welche Kombinationen möglich sind. Unter "klarem Coding" versteht halt jeder auch ein klein wenig was anderes, und der "mismatch" ist "nur" ein Inikator für's Zählen oder den erwarteten Datentyp, nicht mehr (aber auch nicht weniger).

Zitat
...aber vielleicht ist das auch alles ein bisschen Geschmacksache. Mir gefällt der Stil nicht, aber ich will auch meinen Stil niemandem aufzwingen.
Btw.: mir war das am Anfang auch suspekt, und ich bin auch nicht glücklich damit, wie manches von dem, was bestimmte Personen an Inhalten vermitteln wollten, vom Ton her rübergekommen ist. Es ist aber ganz sicher keine reine Einzelmeinung, sonst gäbe es "nur das Buch", und nicht auch noch perlcritic.com bzw. auch die entsprechenden Perl-Packages, mit denen man in etwa dasselbe an Empfehlungen bekommen sollte.
(Und ganz ab von der Prototypen-Geschichte: Mir als Perl-DAM hat das geholfen, noch ganz andere "Klopper" zu finden.)

Heute finde ich das ohne Prototypen und (größtenteils) mit shift persönlich übersichtlicher, mache manches sicher auch noch nicht perfekt und würde z.B. in fhem.pl auch nicht auf den Einsatz von Prototypen verzichten wollen, einfach, weil es zu viele Schnittstellen für Enduser gibt. Und die können in der Tat einiges falsch machen, wenn Funktionen nicht Prototypen-konform aufgerufen werden.
In (gepackagetem) Modulcode sieht das mAn. deutlich anders aus. Da sollte der betr. Modulautor schon wissen, wie er seine Funktionen aufruft.

Aber: Es ist halt anders, und ansonsten bin ich Perl-mäßig eben immer noch eher Lernender.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6221
  • Finger weg von der fhem.cfg
Antw:Timerverwaltung bei vorab unbekannter Timerzahl- best practice?
« Antwort #37 am: 04 Mai 2021, 15:44:35 »
Man mag über Stilfragen hinsichtlich des gegenseitigen Umgangs streiten, aber afaik ist die Kritik an sich nicht unberechtigt. Ich habe jedenfalls in den übernommenen Modulen einige Beispiele gefunden, bei denen ich _glaube_, dass der ursprüngliche Autor nicht mehr wußte, welche Art der Parameter er wollte und welcher Datentyp überhaupt erwartet wird.
Das ist genau das nicht-Argument, das ich meine: Irgendjemand versteht irgendwas nicht, deshalb soll man es weglassen. Hä...?
Wenn der Autor nicht mehr weiß, was er da wollte, wie würde es dann helfen, ein Feature wegzulassen, das genau den Punkt, den der Autor nicht versteht, ein bisschen expliziter macht?
Das Problem ist wohl eher, dass der Autor gepennt hat und das nicht ordentlich dokumentiert hat.

Zitat
Das stimmt nun wieder nur bedingt. Es gibt einige Funktionen in FHEM, bei denen der Prototype mit ($$$$) angegeben ist, aber nur der erste Parameter muss wirklich "content" haben, die anderen können "undef" sein, und es gibt auch Fälle, in denen irgendwas zwischendurch "undef" sein kann, aber hinten was gebraucht wird und Fälle, in denen 2 aus 4 genügen. Alle diese Art Abhängigkeiten bekommt man nicht mit, wenn man die vermeintlich übersichtliche Variante
    my ($hash, $data, $timeout, $response, $toEnable ) = @_
wählt.
Naja, sowas gehört halt in die Doku der Funktion (wenn es überhaupt wichtig ist). Ich wüsste jetzt nicht, warum man das bei der "shift"-Notation besser sehen sollte. Klar, man kann es ein bisschen kürzer schreiben, aber ich kann ja auch meine Zeile oben hinschreiben und dann danach für die, bei denen es darauf ankommt sowas:
$hash // croak "hash missing";

Zitat
"Ganz übel" wird es, wenn es möglich ist, an eine Funktion entweder einen SCALAR oder was anderes (z.B. ein ARRAY) als Argument zu übergeben. Ich nutze das teils, um die weitere Funktionsweise der jeweiligen Funktion umzuschalten.
Bei Verwendung von Prototypen wäre sowas wohl (prinzipbedingt) "verboten" (ob das "guter Stil" ist, ist eine andere Frage, aber da lasse ich mich ggf. gerne beraten, wie es besser geht).
Das finde ich tatsächlich nicht so prickelnd. "Funktionsweise umschalten" klingt doch ganz stark danach, dass es eigentlich zwei Funktionen sein müssten. ...und wenn es denn sein soll, dann kann man an der Stelle einfach Referenzen übergeben und die Unterscheidung mit ref machen. Das ist sowieso sauberer, denke ich.
Und wenn man doch mal eine Funktion machen muss oder will, die mehr Polymorphismus zulassen soll, dann lässt man halt den Prototyp weg. Das bedeutet aber nicht, dass man den Prototypen immer weglassen sollte.

...jetzt muss ich meinen Sohn vom Kindergarten abholen.

Gruß,
   Thorsten
FUIP
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14272
  • "Developer"?!? Meistens doch eher "User"
Antw:Timerverwaltung bei vorab unbekannter Timerzahl- best practice?
« Antwort #38 am: 04 Mai 2021, 16:08:19 »
Das ist genau das nicht-Argument, das ich meine: Irgendjemand versteht irgendwas nicht, deshalb soll man es weglassen. Hä...?
Na ja, ist m.E. eine Frage der Sichtweise: Wenn man nicht begründen kann, warum man etwas braucht, kann man sagen: haben wir schon immer so gemacht, also brauchen wir es, um uns sicher zu fühlen.
Aber die Sichtweise, einfach alle Dinge wegzulassen, für die es keine zwingende Begründung (mehr) gibt, finde ich auch nicht verkehrt.
Warum sich das Leben an dieser Stelle "künstlich" erschweren, wenn es ganz genauso gut auch ohne diese Restriktion geht...?

Das mit der generellen Tendenz zum Weglassen hat übrigens auch ein klein wenig mit Perl an sich zu tun: Da es sowieso an vielen Stellen nicht wirklich eindeutig ist und vieles erlaubt, von dem andere Programmiersprachen nur "Häh...!?!" verstehen würden, gibt es eigentlich keinen Grund, plötzlich überall eine formale Ebene der Restriktion einzubauen, die die Programmiersprache an sich nicht für _erforderlich_ hält.

Man braucht halt in Perl nicht dieselbe mühselige Aufzählung von möglichen Variablen und Datentypen vorneweg, die man von anderswo gewohnt ist und kann flexibel reagieren, je nachdem, ob man eine Referenz auf einen HASH oder was anderes vorgesetzt bekommt...

(Vermutlich wird bei der einen Funktion, an die ich speziell dachte in der Tat eine Referenz übergeben und dann via ref gecheckt, wie es an einer eher untergeordneten Stelle weitergehen muss).

(Und ich glaube, dass man sowohl dem Buchautor wie dem Thread-Ersteller des von Cooltux zitierten Beitrags durchaus unterstellen darf, dass die sehr genau wissen, was sie - bezogen auf Perl allgemein - tun, und was wirklich erforderlich ist. Das mit dem "nicht-Argument" halte ich daher für sehr kurz gegriffen. Ob speziell das Weglassen von Prototypen im FHEM-Kontext immer passt, ist eine andere Frage, und da hatte ich auch zum pauschalen Weglassen insbesondere in fhem.pl schon was geschrieben).
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 26781
Antw:Timerverwaltung bei vorab unbekannter Timerzahl- best practice?
« Antwort #39 am: 04 Mai 2021, 16:08:25 »
Und genau aus diesen Grund steige ich in solche Diskussionen nicht mehr mit ein. Es endet immer im Endlosen.
Ich schaue mir auch an wie erfahrene Entwickler auf CPAN ihre Module darstellen. Dann gibt es auch noch eine Menge Seiten im Netz wo man dazu was lesen kann.
https://www.perl.com/pub/2005/07/14/bestpractices.html/

Am Ende komme ich für mich persönlich zum Schluss das ich es als besseren Programming Stile empfinde.

Nach Torsten seiner Argumentation sind die ersten 10 Module welche ich spontan auf CPAN finde offensichtlich falsch.

Zitat
Ach das. Ich dachte, dass sich das geben wird, weil offensichtlich falsch. Er zeigt in dem Beitrag ja gerade, dass er es nicht verstanden hat. Die weitere Argumentation ist dann "weil ich es nicht verstanden habe (also etwas anderes erwarte) muss es weg". Witzig, dass man der Argumentation irgendeine Bedeutung beimisst.

Ich habe für mich selbst entschieden mich an der Mehrheit des Codestils zu halten. Mag sein das Anfänger oder FHEM Perlentwickler ihn schwer lesen können. 90% der anderen Perlentwickler auf der Welt können es aber.


Grüße
Marko
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
My FHEM Git: https://git.cooltux.net/FHEM/
Mein Dokuwiki:
https://www.cooltux.net

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6221
  • Finger weg von der fhem.cfg
Antw:Timerverwaltung bei vorab unbekannter Timerzahl- best practice?
« Antwort #40 am: 04 Mai 2021, 20:19:48 »
Wenn man nicht begründen kann, warum man etwas braucht, kann man sagen: haben wir schon immer so gemacht, also brauchen wir es, um uns sicher zu fühlen.
Das "haben wir schon immer so gemacht" hätte ich jetzt für ein Argument gehalten, die Prototypen wegzulassen. Ich hatte bisher den Eindruck, dass die "alten Hasen" hier ein gewisses Beharrungsvermögen haben und deshalb die Prototypen nicht wollen.

Zitat
Warum sich das Leben an dieser Stelle "künstlich" erschweren, wenn es ganz genauso gut auch ohne diese Restriktion geht...?
Ich sehe das mit den Prototypen nicht als Restriktion. Ich sehe die "Vorschrift", sie wegzulassen eher als solche.

Zitat
Man braucht halt in Perl nicht dieselbe mühselige Aufzählung von möglichen Variablen und Datentypen vorneweg, die man von anderswo gewohnt ist
Das finde ich auch gut so. Starke Typisierung ist so 80er...

Zitat
Das mit dem "nicht-Argument" halte ich daher für sehr kurz gegriffen.
Naja, dann sollen die Experten halt mal ein richtiges Argument liefern. Bis dahin verwende ich weiterhin die Prototypen. Wenn andere das nicht wollen, dann ist das auch ok.

Und genau aus diesen Grund steige ich in solche Diskussionen nicht mehr mit ein. Es endet immer im Endlosen.
Ich sehe das nicht so verbissen. Ich rede nur gerne über solches Zeugs. Wer es dann am Ende wie macht ist mir egal. Ich selbst halte mich sowieso nur daran, wenn mich jemand dafür bezahlt.

Zitat
Nach Torsten seiner Argumentation sind die ersten 10 Module welche ich spontan auf CPAN finde offensichtlich falsch.
Habe ich etwas von "falsch" oder "richtig" gesagt? Es ist ja alles richtig, nur ist manches halt schöner als manches andere.
Ich war immer davon ausgegangen, dass die meisten Perl-Module ziemlich alt sind und deswegen z.B. keine Prototypen haben. Ich wäre nie auf die Idee gekommen, dass das der neue Stil wäre. So ganz glaube ich das auch noch nicht.

Zitat
Ich habe für mich selbst entschieden mich an der Mehrheit des Codestils zu halten. Mag sein das Anfänger oder FHEM Perlentwickler ihn schwer lesen können. 90% der anderen Perlentwickler auf der Welt können es aber.
Das ist jetzt ein bisschen so wie damals bei VHS, oder? Es ist gut, weil es verbreitet ist....
Tatsächlich ist es beim Programmierstil ein valides Argument, dass es andere auch so machen. Allerdings muss man schon ein bisschen aufpassen, dass man sich damit nicht in den Status Quo eingräbt und Weiterentwicklungen verhindert.

Wie schon gesagt: Ich führe diese "Diskussion" sowieso nur so zum Spaß. Ich bin auch interessiert daran, welche Gründe es für oder gegen bestimmte Entscheidungen gibt. Ich werde deswegen meinen eigenen Stil wahrscheinlich nicht ändern und ich erwarte es auch von niemandem, das zu tun.

Gruß,
   Thorsten
FUIP

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14272
  • "Developer"?!? Meistens doch eher "User"
Antw:Timerverwaltung bei vorab unbekannter Timerzahl- best practice?
« Antwort #41 am: 05 Mai 2021, 08:12:51 »
Vorab mal:
Ich rede nur gerne über solches Zeugs.
Genau so hatte ich das verstanden: Als Frage, warum ich diese Notation verwende.

Zitat
Das "haben wir schon immer so gemacht" hätte ich jetzt für ein Argument gehalten, die Prototypen wegzulassen. Ich hatte bisher den Eindruck, dass die "alten Hasen" hier ein gewisses Beharrungsvermögen haben und deshalb die Prototypen nicht wollen.
Na ja, wenn man sich die existierenden Module ansieht, spricht die Statistik eher dafür, dass die "alten Hasen" bei FHEM Prototypen verwenden, und auch (fast) der gesamte Code in der Doku zu FHEM verwendet Prototypen.

Die verlinkte Diskussion geht eher in die Richtung, dass "der Neuling" (der aber mit Perl an sich sehr vertraut ist und daher auch als "alter Hase" bezeichnet werden darf, oder?) klar Stellung gegen Prototypen bezogen hat und erst mal eine eher verhaltene Antworten von jemandem ebenfalls sehr erfahrenen erhalten hat, die in die Richtung ging "Achtung, das hat ggf. Nebenwirkungen, wenn man das einfach so pauschal fordert" (aber nicht: falsch, veraltet oder neumodischer Unfug)...

Zitat
Ich sehe das mit den Prototypen nicht als Restriktion. Ich sehe die "Vorschrift", sie wegzulassen eher als solche.
Es ging um eine Frage, nicht um eine "Vorschrift". Ich empfinde Prototypen als Restriktion, weil ich hin und wieder halt dann zwischendurch feststelle, dass mir doch noch ein Parameter in der Übergabe fehlt, der zu ergänzen ist, und dann FHEM komplett neu starten muss, wenn die Funktion mit Prototype deklariert war. Neu starten ist im Hauptsystem nicht immer toll.

Zitat
Naja, dann sollen die Experten halt mal ein richtiges Argument liefern.
Bin kein Experte und habe auch nicht überprüft, ob das wirklich so vorbehaltslos in der Doku steht oder woanders kritisch hinterfragt wird:
Prototypen sind primär dazu gedacht, damit man subs definieren kann die sich wie builtins verhalten. Sagt nicht PBP, sagt die Perl Doku
https://perldoc.perl.org/perlsub.html#Prototypes
Zitat
Because the intent of this feature is primarily to let you define subroutines that work like built-in functions,
Für modulinterne Funktionen benötige ich in der Regel nicht das feature, dass die sich wie builtins verhalten...

Kann nur nochmal wiederholen, dass ich als Perl-Novize die Erfahrung gemacht habe, dass es ausgesprochen hilfreich war, perlcritic über den Code laufen zu lassen, weil mir damit auch dann diverses anderes Zeug aufgezeigt wurde, was nicht i.O. war (angefangen mit my $foo = 'baz' if $arg;).
Von daher sehe ich es für mich als passend  an, mich schlicht an diese Expertenempfehlungen zu halten, solange ich es nicht wirklich besser weiß.
(Btw.: niemand ist "gezwungen", seinen Code jetzt und sofort zu ändern. Oder den Beispielcode 1:1 zu übernehmen. Man kann den genausogut mit Prototypen verwenden, wenn man das will, und/oder statt shift die "= (@_)"-Variante.)

Hoffe, das jetzt einigermaßen verständlich klargestellt zu haben und danke für die Frage.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

 

decade-submarginal