Verschachtelte Klassen

[vMief]

Hallo, ich habe grade ein großes Problem mit OOP in PHP. Dazu muss man sagen, dass ich in PHP noch nicht viel OOP gemacht habe, aber in anderen Programmiersprachen.
Mein Problem ist, dass ich einfach ein paar verschachtelte Klassen haben will. Aber PHP gibt mit da immer nur blöde Fehler aus. Ich habe noch keinen Quellcode, da ich noch nicht weiter gekommen bin, als ein paar Zeilen voller Fehler.
Ich möchte ungefähr eine solcher Datenstruktur haben (natürlich noch etwas umfangreicher):

config
--MySQL
\  --$Datenbank
\  --$Benutzername
\  --$Passwort
--Admin
\  --Passwort
\ ...

Aber ich bekomme es einfach nicht auf die Reihe

[Camping_RIDER]

Aloha ;)

Hallo, ich habe grade ein großes Problem mit OOP in PHP. Dazu muss man sagen, dass ich in PHP noch nicht viel OOP gemacht habe, aber in anderen Programmiersprachen.

Ich bin auch kein Held mit PHP-OOP...

Mein Problem ist, dass ich einfach ein paar verschachtelte Klassen haben will.

...dafür kann ich aber Java und bin routiniert in der Objektorientierung in Javascript. OOP kann ich also (eigentlich) schon. Trotzdem hab ich noch nie was von verschachtelten Klassen gehört?!? Klär mich (und den Rest) mal auf...

Grüße,

RIDER

[Matthias Apsel]

Om nah hoo pez nyeetz, Camping_RIDER!

...dafür kann ich aber Java und bin routiniert in der Objektorientierung in Javascript.

Gut, das ich das weiß. Vielleicht ruf ich dich mal an.

Matthias

[vMief]

Om nah hoo pez nyeetz, Camping_RIDER!

...dafür kann ich aber Java und bin routiniert in der Objektorientierung in Javascript.

Gut, das ich das weiß. Vielleicht ruf ich dich mal an.

Matthias

Mit Java kann ich das auch wunderbar. Aber leider kann man das nicht (so leicht) auf einen Server bringen :(

[Camping_RIDER]

Aloha ;)

...dafür kann ich aber Java und bin routiniert in der Objektorientierung in Javascript.

Gut, das ich das weiß. Vielleicht ruf ich dich mal an.

Gerne ;) ich bin (soweit es meine Zeit zulässt) immer auf der Suche nach Herausforderungen ;)

Grüße,

RIDER

[hotti]

hi,

Ich möchte ungefähr eine solcher Datenstruktur haben (natürlich noch etwas umfangreicher):

config
--MySQL
\  --$Datenbank
\  --$Benutzername
\  --$Passwort
--Admin
\  --Passwort
\ ...

Aber ich bekomme es einfach nicht auf die Reihe

Du zeigst eine Verzeichnisstruktur und Du tust gut daran, Deine Klassenhierarchien ebenfalls auf Dateiebene abzubilden. Du kannst das ähnlich regeln wie in Perl, wo in einer Subklasse der doppelte Doppelpunkt '::' erstens die Klassenerweiterung verdeutlicht (z.B. CMS::User, class User erweitert class CMS) und zweitens die dazugehörigen Dateien auf Dateisystemebene einordnet ( CMS/User.pm ist die Datei für CMS::User).

Nun, der '::' hat jedoch in PHP eine andere Bedeutung, ergo brauchen wir da ein anderes Zeichen, z.B. den Unterstrich (class CMS_User extends CMS, Datei: CMS/User.php).

MfG

[vMief]

Du zeigst eine Verzeichnisstruktur und Du tust gut daran, Deine Klassenhierarchien ebenfalls auf Dateiebene abzubilden. Du kannst das ähnlich regeln wie in Perl, wo in einer Subklasse der doppelte Doppelpunkt '::' erstens die Klassenerweiterung verdeutlicht (z.B. CMS::User, class User erweitert class CMS) und zweitens die dazugehörigen Dateien auf Dateisystemebene einordnet ( CMS/User.pm ist die Datei für CMS::User).

Nun, der '::' hat jedoch in PHP eine andere Bedeutung, ergo brauchen wir da ein anderes Zeichen, z.B. den Unterstrich (class CMS_User extends CMS, Datei: CMS/User.php).

Mit freundlichen Grüßen

Öhm, jo. Keine Ahnung. Hast du ein Beispiel? Ich kann mir da grad nichts drunter vorstellen.

Übrigens: Ich will da nichts auf Dateiebene machen, dass soll nur eine einfache Config-Datei werden, also darf das alles auch in eine Datei. Da diese Klassen nur Variablen enthalten, erlaube ich mir das mal :)

[hotti]

hi,

Übrigens: Ich will da nichts auf Dateiebene machen, dass soll nur eine einfache Config-Datei werden, also darf das alles auch in eine Datei. Da diese Klassen nur Variablen enthalten, erlaube ich mir das mal :)

Dein Muster s. Threadeingang, passt sehr gut zum Aufbau einer ini Datei.

MfG

[vMief]

Dein Muster s. Threadeingang, passt sehr gut zum Aufbau einer ini Datei.

Genau das will ich auch machen. Eine in-Datei. Nur halt mit verschachtelten Klassen.

[Camping_RIDER]

Aloha ;)

Schön, dass wir dir weiterhelfen konnten...

Nur halt mit verschachtelten Klassen.

...aber vermeide in Zukunft doch bitte den Term "verschachtelte Klassen" ;) Nicht nur, dass es mir dabei die Zehennägel aufrollt, du suchtest nach dem Begriff verschachtelte Objekte.

Dass das mit den verschachtelten Klassen nicht so recht sein kann, war übrigens das, was dir mein erster Post auch schon sagen wollte. Und du siehst ja selbst, wie weit gestreut die Problemlösungsansätze kamen, bis mal das richtige dabei war. Scheint nicht nur ich fand das nicht eindeutig interpretierbar ;)

Grüße,

RIDER

[dedlfix]

Tach!

Nur halt mit verschachtelten Klassen.
...aber vermeide in Zukunft doch bitte den Term "verschachtelte Klassen" ;)

Naja, der Begriff ist nicht ganz verkehrt. Es war nur nicht das gesuchte. Ich nehme an, vMief meinte damit Klassen, die in ihrem Code weitere Klassen definieren, die entweder privat oder auch öffentlich sein können.

public class foo {
  public class bar {
  }
}

Damit könnte man über new foo.bar() ein Objekt erstellen. Das geht so in Java oder C#, jedoch nicht in PHP. Über Namensräume kann man so etwas jedoch in ähnlicher Weise abbilden.

dedlfix.

[Camping_RIDER]

Aloha ;)

Nur halt mit verschachtelten Klassen.
...aber vermeide in Zukunft doch bitte den Term "verschachtelte Klassen" ;)

Naja, der Begriff ist nicht ganz verkehrt.

Ich korrigiere mich - du hast Recht: in diesem Kontext.

Grüße,

RIDER

[M.]

Mahlzeit,

Nun, der '::' hat jedoch in PHP eine andere Bedeutung, ergo brauchen wir da ein anderes Zeichen, z.B. den Unterstrich (class CMS_User extends CMS, Datei: CMS/User.php).

Meinst du nicht, dass das hier ein perfektes Beispiel für Namespaces ist?

[hotti]

Moin,

Nun, der '::' hat jedoch in PHP eine andere Bedeutung, ergo brauchen wir da ein anderes Zeichen, z.B. den Unterstrich (class CMS_User extends CMS, Datei: CMS/User.php).

Meinst du nicht, dass das hier ein perfektes Beispiel für Namespaces ist?

Mir gings gestern um die Abbildung einer Klassenhierarchie im Dateisystem. Es gibt dafürsprechend gute Gründe, diese sind:

1. der Code wird wartbarer
2. der Code wird überschaubarer

Das bringt die Teamarbeit voran und spart Kosten, das hat sich auch in der PHP-Fraktion herumgesprochen. Leider sind CTOs die auf sowas einen Wert legen, heutzutage sehr sehr selten.

MfG

[M.]

Mahlzeit,

Das bringt die Teamarbeit voran und spart Kosten, das hat sich auch in der PHP-Fraktion herumgesprochen.

Stimmt, leider erst seit kurzer Zeit ;)

Leider sind CTOs die auf sowas einen Wert legen, heutzutage sehr sehr selten.

Das Problem ist, die haben keine Ahnung und auf einen Untergebenen hören ist natürlich völlig unter ihrer Würde.

[hotti]

Mahlzeit,

Das bringt die Teamarbeit voran und spart Kosten, das hat sich auch in der PHP-Fraktion herumgesprochen.

Stimmt, leider erst seit kurzer Zeit ;)

Die tun mir eigentlich leid, weil sie seit ungefähr 10 Jahren das, was in Perl schon immer gut geregelt ist, ständig neu erfinden müssen ;)

Leider sind CTOs die auf sowas einen Wert legen, heutzutage sehr sehr selten.

Das Problem ist, die haben keine Ahnung und auf einen Untergebenen hören ist natürlich völlig unter ihrer Würde.

wir müssen das Thema wechseln, das kommt nämlich grad zur Tür rein :)

Hotte

[M.]

Mahlzeit,

Die tun mir eigentlich leid, weil sie seit ungefähr 10 Jahren das, was in Perl schon immer gut geregelt ist, ständig neu erfinden müssen ;)

Da Perl ca. 10 Jahre älter ist als PHP ist das doch ne normale Sache, oder?

[hotti]

Mahlzeit,

Die tun mir eigentlich leid, weil sie seit ungefähr 10 Jahren das, was in Perl schon immer gut geregelt ist, ständig neu erfinden müssen ;)

Da Perl ca. 10 Jahre älter ist als PHP ist das doch ne normale Sache, oder?

Ja, Freilich. Kannst mir glauben, auch von PHP hab ich mir Einiges abgeguckt :)

Es gibt auch immer wieder Stimmen, die behaupten, dass Perl-OOP gar nicht richtig OOP ist. In der Praxis jedoch, ist das absolut nebensächlich, die Mehrzahl der Objekte (die ich in die Welt hecke) sind reine Datenobjekte, also keine Instanzen irgendeiner Klasse. Und die Methoden, welche diese Daten bewegen, können genausogut ganz ordinäre Funktionen sein. Aber Eines ist sicher: Perl-OOP ist zum Organisieren/Strukturieren von Code hervorragend geeignet.

So kommen wir nun auch zum Thema Namespace, eine zum sauberen Strukturieren von Code außerordentlich wichtige Angelegenheit.

Traits: Ja, mache ich auch in Perl. Die werden bei mir dynamisch an Klassen gebunden, Beispiel:

In eine Seite sollen die Wetterdaten, die Seite wird von class A ausgeliefert. Der Designer baut ein paar Platzhalter ins Template und sagt mir wie die heißen. Ich verpasse dem URL zur Seite ein Attribut trailer=wetter und programmiere den Trait wetter.pm welcher die Platzhalter zum Leben erweckt.

Nun soll das Wetter auch in eine andere Seite, deren URL jedoch ist an class B gebunden. Kein Problem, neues Attribut für den an die Seite zugewiesenen URL setzen: trailer=wetter (wetter.pm hahmer schon), die Platzhalter in die Seite, fertig. Kein Griff in Code class A oder class B. Nur noch konfigurieren und ggf. einen minimalen Code erstellen. Ohne vogelwilde Klassenhierarchien und ohne groß suchen zu müssen, in welchem Verzeichnis die Traits liegen: @INC/Trailer.

MfG

PS: Zur im Threadeingang gezeigten Struktur passt das Pattern Entity Attribute Value (EAV). INI-Dateien bilden dieses Pattern ab. Alle meiner Sub-Klassen erben eine Methode: $self->eav('title', 'Neuer Titel für die Seite');

Method eav() als Getter oder Setter für ein reines Datenobjekt.

Seiten haben Attribute. OOP in der Praxis und nicht als Lehre von Äpfeln, Birnen und Hummeln :)

[Matti Mäkitalo]

Hi,

Nun, der '::' hat jedoch in PHP eine andere Bedeutung, ergo brauchen wir da ein anderes Zeichen, z.B. den Unterstrich (class CMS_User extends CMS, Datei: CMS/User.php).

Meinst du nicht, dass das hier ein perfektes Beispiel für Namespaces ist?

Mir gings gestern um die Abbildung einer Klassenhierarchie im Dateisystem. Es gibt dafürsprechend gute Gründe [...]

Und es gibt bei PHP eine Standardempfehlung (PSR), die genau die Abbildung der Klassenhierarchie auf das Dateisystem beschreibt: PSR-0 bzw. dessen Successor PSR-4. PSR-0 erlaubt noch den Unterstrich als Verzeichnisseparator (weil PSR-0 auch PHP<5.3 erfasst). PSR-4 erlaubt nur noch "richtige" Namespaces, und da wird in PHP eben mit dem Backslash () getrennt.

Also: die Klasse CMS\User gehört in die Datei CMS/User.php (eher src/CMS/User.php).

Der Vorteil von PSR-4 liegt darin, dass es einen Standard-Autoloader gibt, der die Klassen dann auch sofort findet ohne require-Hölle. Weiterhin gibt es dann auf packagist.org tausende Pakete, die sich ebenfalls an diesen Standard halten. Ich kann nur stärkstens empfehlen, dies ebenfalls zu tun.

Bis die Tage,
Matti

[1UnitedPower]

Hakuna matata!

Mein Problem ist, dass ich einfach ein paar verschachtelte Klassen haben will.

Klassendefinitionen lassen sich in PHP nicht verschachteln, aber das möchtest du vermutlich auch garnicht ausdrücken. Du möchtest eine einfach ein paar hierarchische Daten in einer Variablen zusammenfassen. Als Datenstruktur bietet sich dafür eine verschachtelte Hashmap an und in PHP benutzt man dafür Arrays.

config
--MySQL
\  --$Datenbank
\  --$Benutzername
\  --$Passwort
--Admin
\  --Passwort

$config = array(  
   'mysql' => array(  
      'datenbank' => $datenbank,  
      'benutzername' => $benutzername,  
      'passwort' => $passwort,  
   ),  
   'admin' => array(  
      'passwort' => $adminPasswort  
   )  
);  

Und uugreifen kannst du darauf so: $config['mysql']['datenbank']

Du kannst die Arrays auch noch zu Objekten casten:

$config = (object)array(  
   'mysql' => (object)array(  
      'datenbank' => $datenbank,  
      'benutzername' => $benutzername,  
      'passwort' => $passwort,  
   ),  
   'admin' => (object)array(  
      'passwort' => $adminPasswort  
   )  
);  

Dann kannst in gewohnter Objekt-Zugriff-Syntax auf die Einträge zugreifen: $config->mysql->datenbank

[vMief]

Du kannst die Arrays auch noch zu Objekten casten:

$config = (object)array(

'mysql' => (object)array(
      'datenbank' => $datenbank,
      'benutzername' => $benutzername,
      'passwort' => $passwort,
   ),
   'admin' => (object)array(
      'passwort' => $adminPasswort
   )
);

>   
> Dann kannst in gewohnter Objekt-Zugriff-Syntax auf die Einträge zugreifen: `$config->mysql->datenbank`{:.language-php}  
  
Genau so etwas habe ich gesucht. Danke dir.

[Matti Mäkitalo]

Hi,

Mein Problem ist, dass ich einfach ein paar verschachtelte Klassen haben will.

Klassendefinitionen lassen sich in PHP nicht verschachteln, aber das möchtest du vermutlich auch garnicht ausdrücken. Du möchtest eine einfach ein paar hierarchische Daten in einer Variablen zusammenfassen. Als Datenstruktur bietet sich dafür eine verschachtelte Hashmap an und in PHP benutzt man dafür Arrays.

Das (Anti-)Pattern, das du hier verwendest, nennt man auch Primitive Obsession: die falsche Verwendung einer Hashmap, anstatt die Daten korrekt durch Klassen abzubilden.

Es wäre vermutlich deutlich lesbarer, die Daten korrekt abzubilden: eine Klasse Config\MysqlConfiguration, eine Klasse Config\AdminConfiguration, eine Klasse Config. Die Klasse Config hat dann eine Property der jeweiligen Unterkonfigurationen.

Die Struktur der Daten bleibt dann im Wesentlichen gleich (die Daten sind immer noch als Baum abgelegt). Du gewinnst allerdings eine gewisse Typsicherheit, kannst Methoden auf den Config-Objekten definieren usw. Diese Lösung ist (was RAM angeht) auch nicht teurer als die Hash-Lösung, nur ein wenig mehr tippen muss man.

Bis die Tage,
Matti

[dedlfix]

Tach!

Als Datenstruktur bietet sich dafür eine verschachtelte Hashmap an und in PHP benutzt man dafür Arrays.
Es wäre vermutlich deutlich lesbarer, die Daten korrekt abzubilden: eine Klasse Config\MysqlConfiguration, eine Klasse Config\AdminConfiguration, eine Klasse Config. Die Klasse Config hat dann eine Property der jeweiligen Unterkonfigurationen.

Das Array ist zwar einfach aufzusetzen, damit sind die Bezeichner aber "stringly"-typed (ja, i nicht o). Das hat gegenüber der Klassen-Variante auch beim Programmieren einen Nachteil, man muss diese Strings und deren Schreibweise genau kennen. Wenn es Klassen sind, kennt die IDE welche Eigenschaften es gibt und kann mit Autovervollständigen helfen.

dedlfix.

[1UnitedPower]

Hakuna matata!

Es wäre vermutlich deutlich lesbarer, die Daten korrekt abzubilden: eine Klasse Config\MysqlConfiguration, eine Klasse Config\AdminConfiguration, eine Klasse Config. Die Klasse Config hat dann eine Property der jeweiligen Unterkonfigurationen.

Das Gegenteil ist für mich der Fall, durch das Verpacken in Klassen führt man sehr viel Boilerplate-Code ein, der mich persönlich nur von der eigentlichen Problemstellng ablenkt. Zum Vergleich:

class AdminConfiguration {  
   public $password;  
}  
class MySqlConfigration {  
   public $database;  
   public $user;  
   public $password;  
}  
class Configration {  
   public $admin;  
   public $mysql;  
   public function __construct( $admin, $mysql ) {  
      $this->admin = $admin;  
      $this->mysql = $mysql;  
   }  
}  
$admin = new AdminConfiguration();  
$admin->password = 'password';  
  
$mysql = new MySQLConfiguration();  
$mysql->database = 'database';  
$mysql->user = 'user';  
$mysql->password = 'password';  
  
$config = new Configuration( $admin, $mysql );

Die Struktur der Daten bleibt dann im Wesentlichen gleich (die Daten sind immer noch als Baum abgelegt). Du gewinnst allerdings eine gewisse Typsicherheit

Der große Vorteil von Typsicherheit ist, dass man Typfehler sehr früh erkennen kann. Das funktioniert in statisch typisierten Sprachen super gut, weil man da Typfehler schon zur Compilerzeit ermitteln kan. In PHP funktioniert das überhaupt nicht, weil PHP dynamisch typisiert ist, die Typen werden also erst zur Laufzeit bekannt und folglich können auch Typfehler erst zur Laufzeit aufgelöst werden. Das macht das Argument für mich hinfällig.

Und ganz davon abgesehen, halte ich Typsicherheit ohnehin für überbewertet. Eric Elliott spiegelt meine Meinung darüber sehr gut wieder.

Diese Lösung ist (was RAM angeht) auch nicht teurer als die Hash-Lösung, nur ein wenig mehr tippen muss man.

Über Speicherbedarf möchte ich mich gar nicht streiten. Über die Tipparbeit kann ich auch hinwegsehen, aber Code wird sehr viel öfter gelesen als geschrieben und ich persönlich lese lieber prägnanten als aufgedunsenen Code.

“When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.”
– James Whitcomb Riley

[Matti Mäkitalo]

Hi,

In PHP funktioniert das überhaupt nicht, weil PHP dynamisch typisiert ist[...]

Eine gewisse Menge an Typisierung kann man aber durch Type-Hints reinbringen.

  
   public function __construct(AdminConfiguration $admin, MySqlConfiguration $mysql ) {  
      $this->admin = $admin;  
      $this->mysql = $mysql;  
   }  
}  

Code wird sehr viel öfter gelesen als geschrieben und ich persönlich lese lieber prägnanten als aufgedunsenen Code.

Was du leider vergisst: wenn dein Konfigurations-Hash rumgereicht wird an Orte, die weit weg sind von dem Ort, wo er definiert ist, musst du immer nachschauen, wie deine Keys heißen, wie die genaue Struktur aussieht usw. Auch ist die Lösung fehleranfällig, z.B. gegenüber Tippfehlern bei Keys. Bei der Klassenlösung steht es im Vertrag der Klasse und niemand (korrekte Sichtbarkeit der Attribute vorausgesetzt) kann dagegen verstossen.

Eine allgemeingültige Lösung für die Frage "statische/dynamische Typisierung" gibt es IMHO nicht. Bei großen, komplexen Systemen mit vielen Entwicklern kann statische Typisierung (auch in Verbindung mit DDD) viele Vorteile bringen. Und gleichzeitig kann es zu viel Boilerplate in kleinen Projekten führen, bei denen man die Komplexität nicht braucht.

Bis die Tage,
Matti

[1UnitedPower]

Hakuna matata!

Code wird sehr viel öfter gelesen als geschrieben und ich persönlich lese lieber prägnanten als aufgedunsenen Code.

Was du leider vergisst: wenn dein Konfigurations-Hash rumgereicht wird an Orte, die weit weg sind von dem Ort, wo er definiert ist, musst du immer nachschauen, wie deine Keys heißen, wie die genaue Struktur aussieht usw.

Das muss man auch, wenn man die Konfiguration mit Klassen implementiert. Aber das muss man nicht unbedingt im Quellcode machen, dafür ist eine Dokumentation der sehr viel bessere Ort. Moderne IDEs bieten inzwischen vermehrt sehr gute Möglichkeiten, um Dokumentationen verschiedener Arten, schnell zugriffsbereit zu machen.

Auch ist die Lösung fehleranfällig, z.B. gegenüber Tippfehlern bei Keys. Bei der Klassenlösung steht es im Vertrag der Klasse und niemand (korrekte Sichtbarkeit der Attribute vorausgesetzt) kann dagegen verstossen.

Wenn ich mit PHP eine Eigenschaft von einem Objekt lese, und diese Eigenschaft nicht exisitiert, dann wirft PHP eine E_NOTICE, und das völlig unabhängig davon, ob das Objekt die Instanz einer Klasse ist, oder ob es sich dabei um ein planes Objekt handelt.

Wenn ich eine Eigenschaft auf einem Objekt setzen möchte, und die Eigenschaft existiert noch nicht, dann wird die Eigenschaft ohne Fehlermeldung trotzdem angelegt, auch unabhängig davon, ob das Objekt die Instanz einer Klasse ist oder nicht. Das ist das DuckTyping-Prinzip.

Es gibt zur Laufzeit also keine zusätzliche Sicherheit gegen Tippfehler, wenn man Klassen einsetzt. Was dagegen wirklich gegen Tippfehler hilft, ist die Autovervollständigung des Editors, die dedlfix bereits erwähnt hat, und der Einsatz von Code-Quality-Tools aka. Linter, Hinter.

Eine allgemeingültige Lösung für die Frage "statische/dynamische Typisierung" gibt es IMHO nicht. Bei großen, komplexen Systemen mit vielen Entwicklern kann statische Typisierung (auch in Verbindung mit DDD) viele Vorteile bringen. Und gleichzeitig kann es zu viel Boilerplate in kleinen Projekten führen, bei denen man die Komplexität nicht braucht.

Eine allgemeingültige Lösung gibt es nicht, da stimme ich dir zu. Aber die Grenzen verlaufen nicht zwischen großen und kleinen Projekten, auch wenn die Anhänger von statischer Typisierung das gerne so darstellen. Aber es gibt ein entscheidenes Gegenargument: Es werden erfolgreich sehr große Projekte in dynamisch typisierten Sprachen geschrieben. Eric Elliott greift diese Thematik in seinem Talk übrigens auch auf.

[1UnitedPower]

Hakuna matata!

Eine allgemeingültige Lösung für die Frage "statische/dynamische Typisierung" gibt es IMHO nicht.

Weil es hier gerade so gut passt: http://leftoversalad.tumblr.com/post/103503118002

[dedlfix]

Tach!

Der große Vorteil von Typsicherheit ist, dass man Typfehler sehr früh erkennen kann. Das funktioniert in statisch typisierten Sprachen super gut, weil man da Typfehler schon zur Compilerzeit ermitteln kan. In PHP funktioniert das überhaupt nicht, weil PHP dynamisch typisiert ist, die Typen werden also erst zur Laufzeit bekannt und folglich können auch Typfehler erst zur Laufzeit aufgelöst werden. Das macht das Argument für mich hinfällig.

Ganz so schlimm empfinde ich das nicht. Ich finde es wichtig, dass ich aus dem Code ersehen kann, welcher Typ vorliegt, oder vorliegen soll. Deswegen vermeide ich nach Möglichkeit Konstrukte, aus denen man den Typ nicht erkennen kann. Es gibt Unterstützungen in den IDEs, die einem dabei helfen, nicht korrekte Zugriffe bereits beim Code-Schreiben zu erkennen. Und es gibt die PHPDoc-Kommentar-Syntax, die nicht nur der IDE Hinweise auf den verwendeten Typ geben, sondern auch dem Leser. So kann man schon die meisten Typfehler beim Tippen erkennen und muss nicht erst die Ente zu Wasser lassen.Ich empfinde mich produktiver, wenn mir die IDE gleich sagen kann, was nach dem -> oder . geschrieben werden kann, als wenn ich erst in der Dokumentation oder gar dem Code nachschauen muss.

Und ganz davon abgesehen, halte ich Typsicherheit ohnehin für überbewertet. Eric Elliott spiegelt meine Meinung darüber sehr gut wieder.

Aber auch er scheint zumindest Type Hints nicht zu verachten. (Hab im Moment nur den Begleittext gelesen, nicht den Vortrag angeschaut.)

dedlfix.

[1UnitedPower]

Hakuna matata!

Ich empfinde mich produktiver, wenn mir die IDE gleich sagen kann, was nach dem -> oder . geschrieben werden kann, als wenn ich erst in der Dokumentation oder gar dem Code nachschauen muss.

Das ist guter Punkt zum anknüpfen, es geht letztlich ja darum, was einem bei der Arbeit wirklich unterstützt. Für dich und Matti ist ein eher striktes Typsystem dabei offenbar eine großte Stütze. Ich fühle mich dadurch aber häufiger behindert als unterstützt.

Und ganz davon abgesehen, halte ich Typsicherheit ohnehin für überbewertet. Eric Elliott spiegelt meine Meinung darüber sehr gut wieder.

Aber auch er scheint zumindest Type Hints nicht zu verachten. (Hab im Moment nur den Begleittext gelesen, nicht den Vortrag angeschaut.)

Natürlich, es gibt Vorteile, die sind nicht von der Hand zu weisen. In dem Talk geht es auch nicht darum statische Typisierung als überflüssigen Schnick-Schnack zu outen, sondern darum, dass die Rolle, die sie spielt, sehr weit überschätzt wird, dass man die Vorteile mit anderen Werkzeugen supplementieren kann und dass sie noch lange kein Garant für guten Quellcode ist.