Vorstellung: tueena Framework

[rkr]

Was daran erinnert Dich an C#?

C# ist eine von ganz wenigen Sprachen, bei denen Variablen, Properties und Methodennamen großgeschrieben werden.
Das ist etwas, was in der PHP-Welt höchst selten anzutreffen ist.

Wir die Factory auch mit den ggf. benötigten Objekten injected?

Es gibt nicht nur die Factory. Die Factory wird tatsächlich sogar recht selten verwendet. In diesem Fall wird ein Composite-Objekt mit Loggern bestückt. Das lässt sich anders schwer formulieren.
Und ja, du kannst in einer Factory auch auf andere Objekte zugreifen.

Zudem kannst du DI-Container ineinanderstecken, um beispielsweise Module im Code abzubilden, wo jedes Modul leicht abweichende Definitionen haben kann und als Fallback den Parent-Container verwendet.

An sich mag ich es, wenn man explizit programmiert.

Du kannst alles explizit definieren. Macht aber keinen Sinn. Ich habe hier eine größere BackOffice-Applikation, die aus sehr vielen Klassen besteht. Würde ich da alle in die Definition mit aufnehmen, wäre die Konfiguration sehr aufwändig.

Ich finde DI aus dem gleichen Grund auch nicht unproblematisch. Ich denke, ich würde es immer vorziehen, die Service-Objekte, die der Injection zur Verfügung stehen sollen, selbst zu definieren.

Kannst du machen.
Bei DI wird idR alles eager injected. Heißt, bevor deine eigentliche Applikation überhaupt losläuft, sind idR schon alle Dependencies instantiiert und zugeordnet. Allerdings kann PHP-DI auch LazyProxies erzeugen. Dann ist dann sinnvoll, wenn eine Dependency zwar injiziert, aber der Constructor noch nicht invok't werden soll.

Debugging ist immer so eine Sache - aber wir sind an diesem Punkt ja eh schon pro-DI.

Das ist natürlich kein Argument gegen PHP-DI. Nur weil etwas möglich ist, muss man es ja nicht nutzen.

Du kannst das Autowiring-Feature deaktivieren. Aber im ernst: Das macht niemand. Genau so, wie heute niemand mehr auf Autoloading verzichtet.
Man sollte aber wissen, was da passiert.

Was meinst Du?

Wo kommen die Instanzen für Test1 und Test2 her? Wo wurden sie definiert? Du hast das Thema eigentlich schon durchschaut, wenn ich das richtig rauslese.

Sind etwa alle Tab-Verfechter dann verstummt?

Ich werde bei der Diskussion jedes mal zum Torvalds
Ich kann es wirklich nicht verstehen, warum wir uns im Jahre 2016 mit 16:9/16:10-Monitoren wirklich noch drüber streiten, dass bei Tabs nicht garantiert ist, dass eine Zeile nach 80 Columns wirklich zuende ist.
Ja, oftmals ist die Standardeinstellung für Tabs 8 Spaces. Ja, das finde ich auch unglücklich. Aber Spaces als Antwort? Nicht mit mir; Résistance

Also ein Entwickler, der in meinen Code nicht rein kommt, weil nicht PSR vorne drauf steht (und drinnen ist), der hat ein anderes Problem, oder? Das mit der Akzeptanz mag sein - wie man hier sieht, scheint es so zu sein. Und natürlich hat PSR-Konformität den Vorteil, dass IDEs damit eher was anfangen können und man die Coding-Conventions womöglich nicht aufwändig konfigurieren muss, falls bzw. soweit das überhaupt in der jeweiligen IDE möglich ist. Aber he ... das ist doch alles wie die Farbe meiner Unterhosen. Wie viel Zeit verbringen wir der Arbeit an beschissenem Code? Ein Code, der exotische Conventions verwendet, aber eine saubere Architektur hat oder testgetrieben entwickelt wurde ist mir doch allemal lieber, als ein astrein PSR-Formatierter Code voller Design-Fehler usw. Aber gut, es geht ja nicht darum, das eine gegen das andere auszuspielen. Ich verstehe nur nicht, dass es Entwickler gibt, deren einziger Kommentar zu einer Bibliothek ist, dass sie nicht PSR-kompatibel ist. Aber ... ich hab die Kritik vernommen. Und ich bin unschlüssig, ob ich das ändern soll

Ja, die Prinzessin auf der Erbse.
Ne, im Ernst. Wenn ich die Wahl zwischen zwei gleichartigen Komponenten habe, dann dauert es bei mir meistens nur ein paar Sekunden, mich für die ein oder andere Komponente zu entscheiden. Wenn der eine Sourcecode nach Standards formatiert ist und der andere nicht, dann grabe ich nicht weiter. Ich habe die Zeit einfach nicht. Ich gehe einfach blind davon aus, dass der eine sich viel mehr mit dem Beschäftigt hat, was er da tut. Dass ich in der Kürze der Zeit nicht auf jedes Detail ausreichend eingegangen bin, versteht sich von selbst. Wenn eine Komponente eine gewisse Reputation hat, schaue ich idR nicht mal vorab in den Code. Und ich weiß, dass ich mir dieser Art nicht alleine bin
Ich würde nie behaupten, dass dein Code oder gar dein Projekt schlecht ist. Ich weiß, wie viel Arbeit in sowas stecken kann und ich respektiere jeden, der sein Projekt einer breiteren Öffentlichkeit unentgeltlich zugänglich macht. Mache ich auch. Aber das führt nicht automatisch dazu, dass ich jedes Projekt einsetze.
Das ZendFramework und das Symfony-Framework werden von hunderttausenden Entwicklern geschätzt und in genialen Produkten eingesetzt. Ich halte sie für veraltet. Man kann nicht alles jedem Recht machen...

[bfenske]

C# ist eine von ganz wenigen Sprachen, bei denen Variablen, Properties und Methodennamen großgeschrieben werden.
Das ist etwas, was in der PHP-Welt höchst selten anzutreffen ist.

Das Ding enthält ein Objekt! In PHP werden Variablen und Properties, deren Typ eine Klasse ist (bzw. sein soll) schon immer groß geschrieben. Bei Closures kommt es mir selbst ein wenig komisch vor, da diese vom Gefühl her ja eher Funktionen sind. Aber es sind Objekte...

Alles andere später

[hellbringer]

Das Ding enthält ein Objekt! In PHP werden Variablen und Properties, deren Typ eine Klasse ist (bzw. sein soll) schon immer groß geschrieben.

Nope.

Das lese ich jetzt zum ersten mal.

[rkr]

Das Ding enthält ein Objekt! In PHP werden Variablen und Properties, deren Typ eine Klasse ist (bzw. sein soll) schon immer groß geschrieben. Bei Closures kommt es mir selbst ein wenig komisch vor, da diese vom Gefühl her ja eher Funktionen sind. Aber es sind Objekte...

Ich schließe mich da hellbringer an. Das ist höchst unüblich und erinnert an die Ungarische Notation.

[rhofma]

Wie viel Zeit verbringen wir der Arbeit an beschissenem Code? Ein Code, der exotische Conventions verwendet, aber eine saubere Architektur hat oder testgetrieben entwickelt wurde ist mir doch allemal lieber, als ein astrein PSR-Formatierter Code voller Design-Fehler usw.

Sauberer Code testgetriebener Code sollte nicht in konkureenz stehen zum Coding Style Standard. Beides ist wichtig. Ich gucke bei Composer Packages immer den Code an und wenn sich da nicht an gängige Standard gehalten wird, dann guck ich mir das nicht weiter an, weil ich mir dann denke "der hat doch keine Ahnung was er tut.. ewiso sollte ich ausgerechnet sein package nutzen?"..

[bfenske]

[PascalCase für Instanz-Vatiablen]

Hoppla! Ihr habt völlig Recht. Ich hätte meinen Arsch verwettet Kommt vermutlich daher, dass ich bis vor einiger Zeit immer die ungarische Notation verwendet hab, wenn ich die Wahl hatte. War das nichtmal "ganz, ganz" früher üblich? Seid ihr sicher? So zu PHP3-Zeiten oder so? Was waren damals die Trendsetter? Die Pear-Coding-Conventions vermutlich. ... suche im Archiv ... Eieiei, nichtmal bei denen war das definiert. Muss mal grad mein Gehirn wechseln, meins macht komische Sachen ... Entschuldigt bitte meine als Wahrheit hingestellte falsche Behauptung.

Du kannst alles explizit definieren. Macht aber keinen Sinn. Ich habe hier eine größere BackOffice-Applikation, die aus sehr vielen Klassen besteht. Würde ich da alle in die Definition mit aufnehmen, wäre die Konfiguration sehr aufwändig.

Ja, da gebe ich Dir recht, was das Argument "explizite Definition" angeht. Das hilft bei genauerer Betrachtung hier nicht wirklich zum Debuggen oder zum Code-Verständnis und nervt dann nur. Was ich aber nicht verstehe: Heißt das, dass Deine Klassen alle von konkreten Klassen abhängig sind, anstatt von Interfaces? Wie mockst Du die dann in Deinen Tests?

Bei DI wird idR alles eager injected. Heißt, bevor deine eigentliche Applikation überhaupt losläuft, sind idR schon alle Dependencies instantiiert und zugeordnet.

Was ist der Vorteil gegenüber dem Performance-Nachteil? Wäre da nicht ein Tool zum Testen der Definition besser, falls der einzige Vorteil quasi eine Überprüfung auf Richtigkeit der Konfiguration beim Start ist? In meinem Code wird alles erst dann erzeugt, wenn es wirklich gebraucht wird. Sehe keinen Sinn darin, es anders zu machen bzw. es nicht per default so zu machen.

Wo kommen die Instanzen für Test1 und Test2 her? Wo wurden sie definiert?

Soll das ein Test sein?

Ich kann es wirklich nicht verstehen, warum wir uns im Jahre 2016 mit 16:9/16:10-Monitoren wirklich noch drüber streiten, dass bei Tabs nicht garantiert ist, dass eine Zeile nach 80 Columns wirklich zuende ist.
Ja, oftmals ist die Standardeinstellung für Tabs 8 Spaces. Ja, das finde ich auch unglücklich. Aber Spaces als Antwort? Nicht mit mir; Résistance

Ich mag Tabs auch lieber und finde es völlig unsinnig, Spaces zu nehmen. (Die 80-Zeichen-Grenze übrigens ebenso, aber die wird i.d.R. ja nicht als in Stein gemeißelt vorgegeben.) Aber es ist einfach nur unwichtig, solange man konsistent bleibt und nachher nicht lauter Käs in den diffs drinnen hat.

Ne, im Ernst. Wenn ich die Wahl zwischen zwei gleichartigen Komponenten habe, dann dauert es bei mir meistens nur ein paar Sekunden, mich für die ein oder andere Komponente zu entscheiden. Wenn der eine Sourcecode nach Standards formatiert ist und der andere nicht, dann grabe ich nicht weiter.

Wenn sie gleichartig sind, was willst Du dann auch noch vergleichen? Oder was meinst Du damit? Ich empfehle, sich bei einem derartigen Research-Task kurz ein paar Kriterien zu notieren, die für die Library oder das Framework, um die es geht wichtig sind und dann alle Kandidaten danach abzuklopfen. KO-Kriertien, wie Lizenzen natürlich zuerst. Ich würde da nicht am falschen Fleck sparen und irgendwelche Kandidaten nichtmal mehr nach Features anschauen, nur weil im sauberen Code die Variablennamen Underscores drinnen haben, wie von "rhofma" beschrieben. Da werden Dir bei der Review die Kollegen schönen Dank sagen, wenn Du Ihnen den Task präsentierst und von 3 Möglichen Kandidaten 2 raus geflogen sind, weil die Klammern hinten anstatt unten waren und jetzt ein paar Tage drauf gehen sollen, fehlende Features nachzubauen oder andere Nachteile in Kauf genommen werden sollen, die bei den anderen Libraries vielleicht nicht gegeben gewesen wären, was Du Dir aber noch nicht einmal angeschaut hast. Wichtig ist doch, sich ein Gesamtbild zu machen und dann zu entscheiden. Aber das Proble würde warscheinlich schon bei der Planung aufschlagen, weil Research-Tasks ja üblicherweise timeboxed sind und wie viel Zeit will man dafür jetzt veranschlagen?

Nicht falsch verstehen: Ich rede hier nicht von tueena-framework gegen PHP-DI. Ich möchte nur Dich, rhofma, anregen, Deinen Standpunkt diesbezüglich zu hinterfragen.

Ich habe die Zeit einfach nicht.

Haha! Geht von der Zeit auf php.de ab, was?

Ich würde nie behaupten, dass dein Code oder gar dein Projekt schlecht ist.

Ja, danke. Darum geht es ja auch eh nicht. Ich wollte es einfach mal vorstellen und hören, was andere Entwickler dazu sagen.

[bfenske]

(...wie löscht man Beiträge?...)

[bfenske]

Was mir an den Service-Definitionen nicht gefällt ist, dass da so viel statisches Zeugs notwendig ist.

Die Alternative wäre, Strings zu übergeben. An sich finde ich es so (also Objekte zu übergeben) eindeutig sauberer. In dem Fall ist es halt eine API und die sollte man natürlich möglichst "bequem" machen und das spräche wiederum dafür, Strings zu übergeben und die Methode zum Definieren der Services mit dem ganzen Überprüfungskram vollzustopfen. Aber, ich hab mich hier für die etwas gesprächigere Variante zugunsten einer saubereren Abbildung entschieden. Nachteil ist eben, dass man mehr schreiben muss, ein weiterer Vorteil ist, dass man die API gleich dokumentiert hat und nicht erst wissen muss, welcher Parameter was bedeutet.

Und bei der Wahl zwischen statischer Factory-Methode oder new-Operator oder gar Instanz einer Factory, da ist es für mich keine Frage, was besser Lesbar ist.

[ChristianK]

Code soll nicht nur lesbar sein, sondern auch wartbar und diversen Prinzipien folgen (Clean Code, SOLID). Wenn dein einziges Argument für diese Designentscheidung die Lesbarkeit ist, gibt es für mich keinen Grund zu diskutieren - das bringt nichts.

[rkr]

Ja, da gebe ich Dir recht, was das Argument "explizite Definition" angeht. Das hilft bei genauerer Betrachtung hier nicht wirklich zum Debuggen oder zum Code-Verständnis und nervt dann nur. Was ich aber nicht verstehe: Heißt das, dass Deine Klassen alle von konkreten Klassen abhängig sind, anstatt von Interfaces? Wie mockst Du die dann in Deinen Tests?

Meine Klassen sind nicht von einer konkreten Klasse abhängig, denn ich nutze keine statischen Methoden oder Properties in meinen Klassen. Wenn ich einen Typen in der Signatur meiner Methoden (z.B. __construct) verwende, dann verwende ich ein Interface.

Das ist auch noch so ein Punkt, der mich an der PSR stört. Die Java-Jungs wissen, wie Interfaces gehen. Die Müssen nicht mit einem großen "i" beginnen oder auf "...Interface" enden. Ein Interface kann einfach "View" heißen. Eine Implementation davon kann dann "HtmlView" oder so heißen. Dann ist es auch egal, ob der Typ in meiner Signatur eine Klasse oder eine Abstrakte Klasse oder ein tatsächliches Interface ist. Es ist sowieso alles ein Interface. Wenn ich dann eine Klasse habe, die schon überall als Typ in Signaturen verwendet wird, kann ich die Klasse jederzeit in ein Interface umwandeln, wenn ich ein Substitute davon erstellen will. Fürs Unittesting muss ich das nicht. Da kann ich einfach die Basisklasse überschreiben. 50:50 Chance, ob es in einer Situation mehr bringt, auf fertig implementierte Protected Methods einer bereits bestehenden Klasse zurückzugreifen, oder gezwungen zu werden, jede fehlende Methode zu implementieren oder vorhandene zu überschreiben.

Und PHP ist damit mittlerweile auch sehr einsam, dass es keine Methoden-Bodies in Interfaces erlaubt...
Für Klassen innerhalb eines in sich gekapselten Projekts machen Abstrakte Klassen mehr Sinn als Interfaces. Für öffentliche Schnittstellen zu anderen Systemen machen echte Interfaces mehr Sinn.

Was war die Frage? Ich habe für jede Klasse ein echtes Interface? Nein. Brauche ich nicht. Ich kann alles prima mocken.

Was ist der Vorteil gegenüber dem Performance-Nachteil? Wäre da nicht ein Tool zum Testen der Definition besser, falls der einzige Vorteil quasi eine Überprüfung auf Richtigkeit der Konfiguration beim Start ist? In meinem Code wird alles erst dann erzeugt, wenn es wirklich gebraucht wird. Sehe keinen Sinn darin, es anders zu machen bzw. es nicht per default so zu machen.

Es wird nur instantiiert, was tatsächlich benötigt wird. Nur kannst du keine Klasse erstellen, ohne "Irgendwas" für die Parameter im "Constructur" bereitzustellen - auch wenn nicht alle Parameter in allen Methoden einer Klasse eine Rolle spielen. Das ist aber eher Klassendesign. Und das meinte ich mit Eagerness. Bei statischen Aufrufen verhält sich das nämlich anders - aber häufig nicht viel besser, weil man ja hier auch irgendeine Art constructorähnlichem Bootstrapping braucht, dass dann wieder zu komischem Routingcode bei statischen Klassen führt.

Soll das ein Test sein?

Eher eine Anregung. Häufig kommt dann ein "Ja, und wo kommen die nun her?"

Wenn sie gleichartig sind, was willst Du dann auch noch vergleichen? Oder was meinst Du damit? Ich empfehle, sich bei einem derartigen Research-Task kurz ein paar Kriterien zu notieren, die für die Library oder das Framework, um die es geht wichtig sind und dann alle Kandidaten danach abzuklopfen. KO-Kriertien, wie Lizenzen natürlich zuerst. Ich würde da nicht am falschen Fleck sparen und irgendwelche Kandidaten nichtmal mehr nach Features anschauen, nur weil im sauberen Code die Variablennamen Underscores drinnen haben, wie von "rhofma" beschrieben. Da werden Dir bei der Review die Kollegen schönen Dank sagen, wenn Du Ihnen den Task präsentierst und von 3 Möglichen Kandidaten 2 raus geflogen sind, weil die Klammern hinten anstatt unten waren und jetzt ein paar Tage drauf gehen sollen, fehlende Features nachzubauen oder andere Nachteile in Kauf genommen werden sollen, die bei den anderen Libraries vielleicht nicht gegeben gewesen wären, was Du Dir aber noch nicht einmal angeschaut hast. Wichtig ist doch, sich ein Gesamtbild zu machen und dann zu entscheiden. Aber das Proble würde warscheinlich schon bei der Planung aufschlagen, weil Research-Tasks ja üblicherweise timeboxed sind und wie viel Zeit will man dafür jetzt veranschlagen?

Gleichartig heißt nicht Gleich. Alleine bei den Template-Engines gibt es ne menge Auswahl. Die sind häufig gleichartig, aber selten gleich. Und meine Kollegen sind da ähnlich gestrickt, wie ich. Das Argument hat sich bewährt und ist quasi anerkannt. Kollateralschäden werden in Kauf genommen.

Haha! Geht von der Zeit auf php.de ab, was?

Das Verbuche ich unter "Gelerntes Vertiefen" oder "Wiederholung". Hat mir bislang nicht geschadet.

Code soll nicht nur lesbar sein, sondern auch wartbar und diversen Prinzipien folgen (Clean Code, SOLID). Wenn dein einziges Argument für diese Designentscheidung die Lesbarkeit ist, gibt es für mich keinen Grund zu diskutieren - das bringt nichts.

Das passt aber schon. In jeder DI-Config wird so gearbeitet. Das hat auch nichts mit CleanCode oder SOLID zu tun. Die Alternative dazu wäre mit XML oder YAML oder sowas zu arbeiten um die Konfiguration zu modellieren.

[bfenske]

Das hab ich mit "sauberer" nicht gemeint. Soll ich jetzt ausführen, warum ich es vorziehe, einer Methode Objekte zu übergeben, die eine Bedeutung haben, als Strings, die alles mögliche sein können? Puh. Geht es hier überhaupt um fachlichen Austausch oder wird hier nur rumgebrüllt, wer der beste Profi ist? Mann, mann, mann...

[ChristianK]

Ich verstehe einfach nicht, wie das

            ->add(
                IdentifyingType::is(Type::fromName('IHttpRequest')),
                ImplementingType::is(Type::fromName('HttpRequest'))
            ) 

so viel besser sein soll als so etwas:

->add('IHttpRequest', 'Some/Namespace/HttpRequest') 

[rkr]

Ich verstehe einfach nicht

In PHP-DI sieht das so aus:

<?php
namespace DI;
return [
    /* ... */
    IHttpRequest::class => object(Some/Namespace/HttpRequest::class),
    /* ... */
];