[3.3] Recent Topics NG

[LukeWCS]

Hab gesehen, dass du den Fix schon eingereicht hast, aber ohne GH Release. Ich nehme an, du willst erstmal Reaktion abwarten?

Okay, dann gehen wir bei 1.1 auf PHP >=8.0?

[IMC]

Ja, den Release habe ich noch nicht durchgeführt. Das mache ich noch.

Ich muss auch noch die Branches synchronisieren. Mache ich noch heute. Dann kannst du deine Änderungen umsetzen. V1.1 hat dann die PHP >= 8.0.

Das Release 1.1 sollten wir veröffentlichen nach dem wir es mit php 8.5 getestet haben.

Ab Donnerstag bin ich wieder paar Tage offline. (Klassiker Treffen in Sinsheim)

[LukeWCS]

Ja, den Release habe ich noch nicht durchgeführt. Das mache ich noch.

Wobei wir mit GH Release vielleicht wirklich die Vali Reaktion abwarten könnten, weil ich 1.0.1 jetzt nicht so wirklich als dringend einstufe, um das Update sofort und gleich ausrollen zu müssen, oder?

Ich muss auch noch die Branches synchronisieren. Mache ich noch heute. Dann kannst du deine Änderungen umsetzen.

Keine Eile, ich muss jetzt erstmal EMP 3.1 Release machen, daran schraube ich schon inzwischen 1 ganzes Jahr. Aber ich habs auch langsam angehen lassen, ich war noch alle von 3.0.

Wegen 1.1 und 8.5: Konsens

Viel Spass

[IMC]

Wobei wir mit GH Release vielleicht wirklich die Vali Reaktion abwarten könnten, weil ich 1.0.1 jetzt nicht so wirklich als dringend einstufe, um das Update sofort und gleich ausrollen zu müssen, oder?

Ich sehe darin jetzt auch nicht die größte Dringlichkeit. Wir warten die Validierung ab.

Edit:
dev-1.0.1 ist jetzt in dev integriert. Den master lasse ich erstmal wie er ist.

[IMC]

Hi Patrick,
bei mein letzten Commit war ein kleiner Fehler. Deshalb habe ich eben ein "Amend commit..." durchgeführt.

[LukeWCS]

Alles klar. Und wenn du mal im Dev Branch nen Reset auf einen vorherigen Commit brauchst, gib einfach Bescheid. Aber Amend tuts auch.

Luke hält Crizzo die Ohren zu

Solange RTNG nicht geforkt wird, haben wir Narrenfreiheit.

[IMC]

Solange RTNG nicht geforkt wird, haben wir Narrenfreiheit.

Dann hoffe ich für mich, dass dies noch eine Weile so bleibt.

Heute Morgen habe ich mir meinen Code von gestern noch einmal angeschaut. Dabei sind mir einige Dinge am Rande aufgefallen (Wieso eigentlich erst jetzt?), die zum Teil schon seit Version 2.2.13 bestehen.

Insgesamt konnte ich 39 Zeilen weg optimieren. Der Commit ist online.

[LukeWCS]

Wieso eigentlich erst jetzt?

Du weisst doch; das ist ein Naturgesetz beim Programmieren, dass man Fehler und Optimierungspotential immer erst DANN entdeckt, wenn das Update schon raus ist. Das Universum hat einen seltsamen Humor.

Insgesamt konnte ich 39 Zeilen weg optimieren.

Die Optimierung selber kann ich grad aus dem Stand nicht bewerten, da dürften noch andere Komponenten in anderen Dateien eine Rolle spielen. Aber der Umfang der Optimierung ist schon erheblich. O_o

[IMC]

Aber der Umfang der Optimierung ist schon erheblich. O_o

Am Ende war ich auch überrascht das danach alle meine Tests positive verliefen.
Zum Teil waren es identische Bedingungen die abgefragt wurden und die Funktion topic_status(), die dreimal aufgerufen wurde. Der Trick war am Ende die richtige Reihenfolge der Zuweisungen und Bedingungen.

ein Naturgesetz beim Programmieren

Wie wahr. Ich mache nochmal ein Amend. Unnützer ternärer Operator.

Und wo wir gerade bei einem ähnlichen Thema sind.
Zur Zeit ist im Code count($topic_icons) ? true : false
Man könnte statt dessen auch !!count($topic_icons) schreiben.

Welche schreibweise sollten wir in Zukunft bevorzugen. Das letztere kann man schneller lesen, aber auch schneller überlesen.

Edit:

danach alle meine Tests positive verliefen.

Doch nicht. Bin beim Testen wohl durcheinander gekommen. Ein Fix habe ich schon. Möchte aber noch die Ursache für das Verhalten ergründen.

2. Edit:
Fix ist online. Wenn nur ungelesene Topics angezeigt werden sollen liefert die Methode gettopiclist() keine Daten um das Array $topic_tracking_info[] zu füllen. Dies ist auch nicht notwendig da nur ungelesene Topics gelistet werden. Daher kann der Marker ungelesen pauschal gesetzt werden.

[LukeWCS]

Zur Zeit ist im Code count($topic_icons) ? true : false
Man könnte statt dessen auch !!count($topic_icons) schreiben.

Welche schreibweise sollten wir in Zukunft bevorzugen. Das letztere kann man schneller lesen, aber auch schneller überlesen.

Gerade mal im Dev Branch geschaut, das Konstrukt haben wir aktuell insgesamt 2 mal. Also ? true : false ist zwar klar verständlich, aber auch sperrig und umständlich. Ich bevorzuge schon länger klare Casts, weil das sowohl kompakt, als auch unmissverständlich ist. PHP Beispiel:

https://github.com/LukeWCS/ext-mgr-plus ... hp#L78-L93

Beim Doppel-Nicht-Operator könnte ich aber auch mitgehen, ich habe das auch schon genutzt. Allerdings bei Javascript, denn eine Funktion nutzen um einen Typ zu deklarieren/konvertieren, ist für mich schon bisserl... bizarr. JS Beispiel:

https://github.com/LukeWCS/ext-mgr-plus ... js#L75-L76

Bei !! könnte sich allerdings mancher Entwickler fragen, welche undokumentierten Tricks wir da benutzen. ^^ Spielt für uns aber unterm Strich keine Rolle, denn innerhalb des vorgegebenen Rahmens (Vorgaben und Richtlinien) haben wir alle Freiheiten. Wir gestalten den Code deshalb so, wie er uns beiden am besten gefällt und wie wir am besten damit klarkommen. Und da spielt halt auch eine Rolle, dass wir schon programmiert haben, als es noch gar kein phpBB gab.

Meine Tendenz wäre Cast (oder Type Juggling wie das bei PHP heisst), denn das wäre dann einheitlich auf alle Typen anwendbar.