Schönes Wochenende bis dahin :)

Gebohren hiess ich Kahwe Haddad, in der Grundschule wurde ich dann offiziell adoptiert, habe dabei den Nachnamen meines Vaters angenommen und habe die Gelegenheit genutzt um meinen Vornamen nach Lukas dem Lokomotivfuehrer umzubennen :)

Meine Muttersprache ist Deutsch, aber mein Englisch ist auch recht fluessig :)

Ich spreche jetzt mal nur aus der Perspektive eines Anwenders, nicht eines Framework-Coreentwicklers (ist die einzige, die ich habe und halbwegs kompetent vertreten kann):

Ich sehe die “Magie” tatsächlich allenfalls als “Add-In”, keinesfalls als Ersatz für den bestehenden Mechanismus des Dependency-Managements.

Dennoch muss die Magie aus meiner Sicht einfach und generalisiert genug sein.

Das FrameworkExtraBundle erfüllt mit einer Menge Code “unter der Haube” einige wenige, spezielle Tasks – und das durch Annotationen, die zwar eventuell aus einer langen Zeile Code eine kurze machen – das “eigentliche” Problem, das mir unter den Nägeln brennt, nämlich ein vereinfachtes Projektmanagement in der IDE durch funktionierende Code-Completion bereitzustellen – nicht löst.

Wer vornehmlich in Textmate entwickelt, ist von diesem Problem nicht berührt – zugegeben.

Autowiring ermöglicht es, wie beschrieben durch Konventionen (Variablennamen) oder “Compilerhints” (Annotationen) durch den DIC verwaltete Objektinstanzen konkret und transparent mir Referenzen “zu befüllen” – mit dem Nachteil, dass man sich dann eben an den DIC koppelt.

Das Feature kann demnach auch nur ein domänenspezifisches sein. Für Controllerklassen macht es aus meiner Sicht wirklich Sinn, denn die Dinger sind nichts anderes als unliebsame “Stubs” ohne wirkliche Businesslogik, die einem bestimmten, immer gleichbleibenden Zweck dienen.

Ein Controller hat IMMER eine Abhängigkeit zum Routing (wenn ich nicht gerade was View-zentrisches benutze wie JSF oder so), zur View ebenso – warum also nicht auch generell zum DIC?

Ich weiß nur, dass sich das Konzept des Autowiring (das auch hinter dem von Dir genannten Link vorgeschlagen wird) in anderen Tools definitiv bewährt hat, doch wie gesagt – nur im eng abgesteckten Rahmen. Es macht definitiv keinen Sinn, einen komplexen Objektgraphen voller Business-Logic ausschließlich durch einen DIC + Autowiring zu verwalten.

Leider hat das ganze auch einen zweiten, großen Nachteil: Da PHP dynamisch typisiert ist und auch keine Type-Hints an Instanzvariablen erlaubt, hat ein wie auch immer gearteter Autowiring-Mechanismus arge Probleme, die benötigte Dependency zu identifizieren. Man käme also eh nicht umhin, eine autowired Property gleich zweimal zu annotieren: Einmal eine Annotation für den DIC (mit dem eindeutigen Identifizierer der Dependency), und einmal mit @var für die IDE. Darüber hinaus: Keine Interface-Injection durch Property-Wiring, das wär’ dann höchstens durch annotierte Setter möglich.

Trotzdem: Ich möchte gerne Code-Completion “out of the box”, das ist mit eines der wichtigsten Features, um wirklich effizient zu arbeiten – aus meiner Sicht.

Abschließend noch eine persönliche Frage, wenn Du erlaubst: Ist Deine Muttersprache Deutsch oder Englisch? Dein Name klingt so “Denglisch” ;)

Danke nochmal für Deinen Beitrag, ich schau mir das auch nochmal genau an und versuche vor allem, die Cons zu kapieren – ist gar nicht so einfach, das wird schon sehr schnell ganz schön akademisch …

Ansonsten drehst du dich ja da ein bisschen im Kreis. Zum einen willst Du lieber Magic, wenn du dann ganz einfach solche Magic nachruesten kannst (aka deine persoenliche Basis Controller Klasse) dann wird das wieder als Schwaeche gewertet.

Das ganze Konzept von Symfony2 ist das man alles sauber machen kann. Das ist die Grundvorraussetzung, dass man sich nicht in eine Sackgasse begibt. Es gibt immer einen sauberen Weg.

Jedoch das heisst ja nicht das man nicht mehr Magic rein bauen kann oder darf. Siehe z.B. FrameworkExtraBundle. Nur das gute ist wenn man damit an die Grenzen stoesst, dann kann man das halt auch easy wieder weglassen und durch andere oder gar keine Magic ersetzen.

Und ja .. derzeit verbringen wir viel Zeit damit die Out of the Box Experience so einfach wie sinnvoll zu machen. Am besten schaltest Du Dich aktiv in die Diskussionen ein:
https://github.com/symfony/symfony/issues?labels=Service+Container