PBP: Warum sind Prototypen schlecht?

[RichardCZ]

deshalb steht da oben ja auch: kommentarlos...

ich sehe nirgendwo eine information oder erklährung

siehe PBP Seite 13/14

aber ist bestimmt wieder nur ein billiger Taschenspielertrick.

[SCMP77]

Das Argument, Prototypen erlauben "durch einen einfachen Blick darauf" eine wie auch immer geartete Analyse bzw. Erkenntnis des Codes dahinter halte ich für einen billigen Taschenspielertrick.

Jein. Bei der ganzen Diskussion sollte man nicht vergessen, dass Perl schon zur Kompilierzeit dort anhand dieser Prototypen gewisse Checks macht. Schafft man die Prototypen ganz ab, werden solche Fehler erst zur Laufzeit erkannt.

Bei FHEM ist das leider aktuelle so, dass solche Fehler meist bewirken, dass das ganze System steht. Kompilierfehler führen dazu, dass das Modul erst gar nicht eingebunden wird und so das System nicht blockiert. Ich bin daher sehr skeptisch, Prototypen ganz weg zu lassen. Ein "Taschenspielertrick" ist aus meiner Sicht nicht. Sicher, es gibt auch tausend andere Möglichkeiten, durch Modulfehler FHEM zum stehen zu bekommen, weil alles seriell abgearbeitet wird, insofern finder man so nur relativ wenig Fehler durch den Kompiler selber, aber die Frage wäre, ist es wirklich notwendig auf diese zu verzichten?

[RichardCZ]

Jein. Bei der ganzen Diskussion sollte man nicht vergessen, dass Perl schon zur Kompilierzeit dort anhand dieser Prototypen gewisse Checks macht. Schafft man die Prototypen ganz ab, werden solche Fehler erst zur Laufzeit erkannt.

<loriot>
ach?
</loriot>

Bleiben wir doch bei parseParams

Code Auswählen Erweitern

sub
parseParams($;$$$)

Bitte welche "gewissen Checks" werden da gemacht?

Der hier? parseParams(\{})

$VAR1 = [
          'REF(0x557396b73948)'
        ];
$VAR2 = {};

Der? parseParams([]) Der? parseParams(\[]) oder der? parseParams([],\{},'blah', *FH);

Wacht auf Leute - all das und noch viel mehr akzeptiert die gegenwärtige parseParams Deklaration mit ihren Protos anstandslos (Compile & Laufzeit). Haben alle eure Fata Morganas Türgriffe oder wie schafft Ihr es euch so beharrlich daran festzuklammern?

Ich bin natürlich gemein. ($;$$$) ist nämlich genau so ein Feigenblatt wie (.*) in regulären Ausdrücken und macht es einfach dieses Konzept "vorzuführen".

Kompilierfehler führen dazu, dass das Modul erst gar nicht eingebunden wird und so das System nicht blockiert.

Da sollte normalerweise eigentlich schon ein pre-commit hook im Subversion eingreifen, so dass ein Modul mit Kompilierfehlern gar nicht erst ins Repo käme. Andere Baustelle.

Ich bin daher sehr skeptisch, Prototypen ganz weg zu lassen. Ein "Taschenspielertrick" ist aus meiner Sicht nicht.

Ich gehe davon aus, ihn oben explizit aufgedeckt zu haben.

Sicher, es gibt auch tausend andere Möglichkeiten, durch Modulfehler FHEM zum stehen zu bekommen, weil alles seriell abgearbeitet wird, insofern finder man so nur relativ wenig Fehler durch den Kompiler selber, aber die Frage wäre, ist es wirklich notwendig auf diese zu verzichten?

Meine Absicht ist es, den FHEM Code so 100x robuster zu bekommen als er jetzt ist. Das für sich genommen ist schon eine Herkulesaufgabe, selbst wenn alle am gleichen Strick ziehen (und nicht diesen anderen drehen). Stattdessen muss ich hier "rechtfertigen", warum man nicht versuchen sollte einen kaputten Auspuff mit Tesa und Papiertaschentüchern zu reparieren. Das schlaucht.

Aber nein, keiner muss auf seine geliebten Protos verzichten. Wer mag, darf sie behalten. Ich empfehle halt die zu entfernen, werde das für mich und meinen Code machen.

[CoolTux]

wenn du im modul hash parseParams setzt wird deine SetFn nicht mehr mit der string liste sondern mit dem ergebnis von parseParams aufgerufen.

siehe  DevelopmentModuleIntro seite im wiki

Vielen Dank Andre. Ich habe ASC auf parseParams umgebaut und es klappt super.


Grüße

[justme1968]

zu den klammern für buildins:

die regel sagt: 'nicht tun', die begründung gibt (wie vermutet) keinen technischen grund sondern ein 'ich finde es übersichtlicher' also lass sie weg. ausser wenn sie doch nötig sind.

das ist genau die art von argumenten die komplett sinnlos sind wenn man a) etwas anderes übersichtlicher findet und/oder b) auf konsistenz wert legt und/oder c) sich an existierenden code anlehnt um kein durcheinander zu schaffen.

sich darüber zu streiten welcher stil der richtige ist ist genau das was wir nicht brauchen um fhem besser zu machen.

[RichardCZ]

sich darüber zu streiten welcher stil der richtige ist ist genau das was wir nicht brauchen um fhem besser zu machen.

Die Welt ist größer. Immer.

Es geht hier nicht um Dich, oder um mich. Es geht auch nicht um FHEM alleine.

Ich finde es schon nett, wenn ich einen 5,6,7 Jahre alten Code von jemandem sehe, wo ich mich inhärent zurechtfinde, weil er so

Code Auswählen Erweitern


$attr{$name}{unit_windspeed}      //= "km/h";
$attr{$name}{unit_solarradiation} //= "lux";
$attr{$name}{round}               //= 4;


und nicht so

Code Auswählen Erweitern

    $attr{$name}{unit_windspeed} = "km/h"
      if ( !defined( $attr{$name}{unit_windspeed} ) );
    $attr{$name}{unit_solarradiation} = "lux"
      if ( !defined( $attr{$name}{unit_solarradiation} ) );
    $attr{$name}{round} = 4 if ( !defined( $attr{$name}{round} ) );


aussieht. Ich finde es schon toll, wenn ich auf perl.org, blogs.perl org einen Code von Leuten sehe, die sich an PBP halten, weil - ob Du es glaubst oder nicht - das ist nunmal Standard "da draussen" und ich mich gleich zurechtfinde.

Oder wenn ich die Synopsis moderner Module lese und die auch nicht aussieht wie Kraut und Rüben. Und ja, der FHEM code sieht in weiten Teilen wie Kraut und Rüben aus. Mein parseParams ist schon jetzt wesentlich besser als das Originale, weil ich einige PBP Prinzipien angewendet habe.

Wenn Du das nicht einsiehst und sagst "Geschmacksfrage". ¯\_(ツ)_/¯ Dann lügt sich einer von uns in die Tasche.

Ich schreibe heutzutage besseren Perl Code dank PBP und dank der "Habits" die ich mir wegen PBP angeeignet habe. Genauso wie viele meiner Kollegen und es ist eine WOHLTAT, Code von jemand Fremden in die Hand zu bekommen und sich darin so zurechtzufinden als sei es der eigene.

Wenn man alleine in seiner Hütte sitzt und individuellen autodidaktischen Perl Code zusammenstöpselt, dann ist das ja ok, aber die Welt ist eben größer als die eigene Hütte. Immer.

Und es kommt halt nicht gut, wenn Du z.B. in Deutschland mal mit Deinem Auto aus der Hütte rausfährst und erstmal in der linken Spur fährst, die Verkehrszeichen missachtest und Fernlicht als Blinker und Blinker als Fernlicht benutzt.

[rudolfkoenig]

Wenn man diese Argumentation akzeptiert, und sie konsequent anwendet, muss man jegliche Vielfalt (wofuer Perl mAn steht) unterdruecken.
Ich bin dagegen.

[justme1968]

auch wenn völlig klar ist welche der beiden lesbarer ist haben diese beiden beispiele absolut nichts mit der klamer verwendung für buildins zu tun. also thema verfehlt.

wenn du 5-7 jahre alten code besser verstehst wenn er gerade zufällig die regeln einhält die dir genehm sind ist das schön. gilt aber in der verallgemeinerung nicht für alle. andere verwenden aus genau so gutem grund andere regeln und freuen sich wenn sie diese wieder finden.

ja. genau. 'da draussen' ist größer als es deine pbp welt zulässt.

der stvo vergleich hinkt leider. es gibt genau eine stvo. die jeder einzuhalten hat. aber mehr als eine art klammern zu setzen oder seinen code zu formatieren. alle mit genau so guten begründungen. auch wenn es dir nicht passt.

bleib lieber bei deinem bibel vergleich. der passt besser. auch wenn es schade ist das die vielen zufälligen regeln den blick auf die übrigen sinnvollen und begründbaren verstellen.

[RichardCZ]

Wenn man diese Argumentation akzeptiert, und sie konsequent anwendet, muss man jegliche Vielfalt (wofuer Perl mAn steht) unterdruecken.
Ich bin dagegen.

Das wofür Perl steht weiß ich und der PBP Autor sehr gut. Ich möchte zitieren:

"there's more than one way to do it" (TMTOWTDI) ausgesprochen: "Tim Toady"

Ja, dafür steht Perl.

Aber das heißt noch lange nicht - dass alle diese Wege gleich gut sind.

PBP bedeutet auch nicht, dass man ein Korsett vorgesetzt bekommt, das es einem unmöglich macht irgendwelche Freiheitsgrade auszunutzen.
Und nochmal: Nix von alldem hier ist Pflicht, wer Kraut und Rüben möchte, soll Kraut und Rüben haben.

Allerdings ist dies aus operativer Sicht extrem kurzsichtig. Dir ist doch wichtig, dass Module nicht verwaisen. Mir auch.
Ein PBP-konformes Modul ist für den Modulautor wesentlich einfacher als irgendein individuelles Kraut/Rüben Feld.

Warum?

Bei Problemen mit dem Code findet er einfacher Hilfe, weil es für potentielle Helfer einfacher ist "durchzusteigen" durch den Code.
Wenn er irgendwann nicht mehr Maintainer sein kann oder will, ist die Aufgabe einen Nachfolgemaintainer zu finden einfacher, weil das Modul nicht unter die Kategorie "Oh Gott, was habe ich mir da eingehandelt" fällt.

Ich rede da aus Erfahrung.

[RichardCZ]

auch wenn völlig klar ist welche der beiden lesbarer ist haben diese beiden beispiele absolut nichts mit der klamer verwendung für buildins zu tun. also thema verfehlt.

Die beiden Beispiele haben EXAKT damit zu tun, was mit dem FHEM code passiert, wenn man mit PBP Brille drüberrutscht. Thema nicht erkannt.
Vielleicht versuchen ein wenig Abstand zu gewinnen, dann sieht man auch einfacher das "big picture".

[SCMP77]

Ich finde es schon nett, wenn ich einen 5,6,7 Jahre alten Code von jemandem sehe, wo ich mich inhärent zurechtfinde, weil er so

Code Auswählen Erweitern


$attr{$name}{unit_windspeed}      //= "km/h";
$attr{$name}{unit_solarradiation} //= "lux";
$attr{$name}{round}               //= 4;


und nicht so

Code Auswählen Erweitern

    $attr{$name}{unit_windspeed} = "km/h"
      if ( !defined( $attr{$name}{unit_windspeed} ) );
    $attr{$name}{unit_solarradiation} = "lux"
      if ( !defined( $attr{$name}{unit_solarradiation} ) );
    $attr{$name}{round} = 4 if ( !defined( $attr{$name}{round} ) );


Du darfst hier auch nicht vergessen, es gibt hier viele Leute, welche sich nur (fast) zwangsweise mit Perl beschäftigt haben, weil sie für die eigene Haussteuerung ein bisher nicht vorhandenes Modul benötigt haben. Manch einer hat sich da eine ganz private Anwendung geschrieben, manch anderer hat es dann der Allgemeinheit zur Verfügung gestellt.

Das gilt jedenfalls für mich. Ich bin kein Perl-Experte und ehrlich, ich will es auch nicht werden, weil für mich eine datentypdefinitionslose Programmiersprache ein graus ist (zumindest bei größeren Projekten) und dieses Gewurschtel mit @$\ kommt dann noch dazu. Ja, Pointer gab es auch in C, aber ich war froh, dass man das dann bei C++ kaum mehr benötigte, nur noch referenziert oder nicht war dort noch wirklich sinnvoll. Bei Java hat man selbst diese Untersacheidung abgeschafft, bei Objekten arbeitet man immer mit Referenzen. Ich progarmmiere daher  Perl möglichst "Java-like", weil ich mich auch nicht in Perl tief einarbeiten will. Perl lässt einem eben die Freiheiten, dass man es mit ein paar mehr Zeilen dann auch zum Laufen bekommt. Müsste ich mich erst mit der Bedeutung von //= rumschlagen, hätte ich sicher einen  großen Bogen um FHEM gemacht. Perl erlaubt glücklicherweise es auch so zu schreiben:

Code Auswählen Erweitern


if ( !defined( $attr{$name}{unit_windspeed} ) ) {
    $attr{$name}{unit_windspeed}= "km/h ";
}


Das ist noch umständlicher, als der von Dir bemängelte Code, ist aber eben fast so, wie ich es seit Jahrzehnten von C/C++/Java gewöhnt bin, ganz nach dem Perl-Motto ,,There is more than one way to do it".

Ich lerne gern auch bei Perl dazu, aber es muss auch wirklich einen tieferen Sinn ergeben.

[RichardCZ]

Du darfst hier auch nicht vergessen, es gibt hier viele Leute, welche sich nur (fast) zwangsweise mit Perl beschäftigt haben, weil sie für die eigene Haussteuerung ein bisher nicht vorhandenes Modul benötigt haben.

Ich vergesse das nicht und ich kann mir sehr gut vorstellen. dass es für so Manchen eine regelrechte Qual sein kann sich unter diesen Umständen mit Perl auseinanderzusetzen. In genau der Situation werden Witzchen wie "Perl ist von Bildschirmrauschen nicht zu unterscheiden" den Maintainern das Lächeln eher gefrieren lassen.

Mein Versuch ist daher zu zeigen (und wer will - auch konkret an seinem Code zu helfen - so lange der Zeitvorrat reicht) wie man den Code zumindest so sauber bekommt, dass wenigstens das "Entziffern" nicht schon die kognitive Last auffrisst - die man ja eigentlich für die Funktionalität braucht.

Von daher bin ich bei einigen Modulen ehrlich gesagt schwer beeindruckt, wie sich der Betreffende trotz dieser Qual (die man dem Code ansieht), dennoch durchgegraben hat und etwas auf die Beine gestellt hat.

Ich bin nicht hier um dieses Werk zu kritisieren, ich bin hier um ihm zu helfen - wenn er will - dass dieses Werk evtl. weniger Qual/weniger Supportaufwand und robuster wird und ihm nicht irgendwann komplett über den Kopf wächst oder auf die Füße fällt. Weil das ist dann die Situation, wo ein Modul verwaisen kann.

Ich bin kein Perl-Experte und ehrlich, ich will es auch nicht werden,
...
Perl erlaubt glücklicherweise es auch so zu schreiben:

Code Auswählen Erweitern


if ( !defined( $attr{$name}{unit_windspeed} ) ) {
    $attr{$name}{unit_windspeed}= "km/h ";
}


Das ist noch umständlicher, als der von Dir bemängelte Code, ist aber eben fast so, wie ich es seit Jahrzehnten von C/C++/Java gewöhnt bin, ganz nach dem Perl-Motto ,,There is more than one way to do it".

Ich lerne gern auch bei Perl dazu, aber es muss auch wirklich einen tieferen Sinn ergeben.

Also ich wiederhole noch einmal: Alles was wir hier besprechen ist optional.

Wer  if ( !defined( $attr{$name}{unit_windspeed} ) ) { $attr{$name}{unit_windspeed}= "km/h "; }
statt //= schreiben will, soll das machen. Wenn es dadurch ein Modul gibt, das zwar "Kraut & Rüben" Perl Code ist, aber mit Device X redet, dann ist das 100x besser, als gäbe es ein perfektes elegantes Perl Modul ... gar nicht.

Wie schon in den "Worten zur Motivation" gesagt: Egal wie der Code ist, es ist besser als wäre er nicht.



Ich bin auch kein Profi-Bauherr und will es ehrlich gesagt nicht werden, weil ein Haus reicht. Aber ich kenne den Unterschied zwischen Häusern, die Leute so mit "Bordmitteln" zusammengeschustert haben und Häusern, wo zumindest Profis zu Rate gezogen wurden. (kompetente Profis - nicht nur solche mit der Visitenkarte Profi).

Ich muss zwar dann darin wohnen, aber genau deswegen werde ich trotzdem eine Innenarchitektin meinen Wohnzimmer/Küche/Halle/Wintergarten/Pool/Bad-Erdgeschoss-Komplex projektieren lassen und da nicht selbst reinknödeln, Ich kann sagen was mir wichtig ist, aber ansonsten höre ich ihr sehr aufmerksam zu.

[RichardCZ]

Es sei angemerkt, dass wenn man erstmal die Prototypen los ist, dass es auch so etwas wie "Forward Deklaration" nicht gibt.

z.B. in fhem.pl - kann man ersatzlos knicken:

# configDB special
sub cfgDB_Init;
sub cfgDB_ReadAll;
sub cfgDB_SaveState;
sub cfgDB_SaveCfg;
sub cfgDB_AttrRead;
sub cfgDB_FileRead;
sub cfgDB_FileUpdate;
sub cfgDB_FileWrite;