2009-08-24T12:23:43 freddy

Da habt Ihr bestimmt Recht.

Aber mal einen Fall angenommen: Du hast eine zentrale Konfig im Hash %config stehen. Wäre doch toll und codesparend, wenn man projektweit auf diese %config zugreifen könnte, ohne für jede sub übergeben zu müssen.

Wie rennee sagte sollte nicht "codesparend" das ziel sein, sondern eine saubere vernünftige, skalierende lösung die keine Probleme bereitet.

Von daher würde ich eine Config Datei in einem Objekt/Klasse auslagern worauf zu zugriff hast.

Und wenn du sowieso schon ein großes Projekt hast macht es dann sinn das du dieses Objekt beim starten lediglich einmal initialisierst und dann mit dir rum führst. Als Beispiel nehme ich mal Catalyst, du hast jederzeit in Catalyst zugriff auf die Config datei indem du



aufrufst.

Quote

Da als Prämisse festgelegt ist, das es nirgendwo ein zweites config geben darf, würde das doch passen, oder?

Ich würde Code niemals programmieren auf solche anforderungen hin. Ganz einfach deswegen weil solche Sachen sich ändern können. Und wenn diese sich ändern dann steht ihr am ende ziemlich dumm dar wenn ihr soetwas nicht von vorneherein eingeplannt habt.

Und nachträglich etwas anzupassen ist immer die Qual.

Ansonsten nur so nebenbei mal ein Beispiel. Du kannst z.B. "use Config" machen. Dann importiert Perl dir eine Variable "%Config".

Okay du hast glück das du jetzt von %config sprachst, dass macht dann zum Glück keine Probleme, was wäre aber wenn du es %Config genannt hast? Oder noch anders, du benötigst beides.

Dann hast du irgendwo aufrufe mit $Config{...} und woanders $config{...} stehen.

Das ist schwer zu durchschauen und verwirrend für einen Leser.

Ein weiterer Punkt, stell dir vor du nutzt ein Modul und das importiert dir ebenfalls eine %config variable. Ich meine %config als Konfiguration zu nutzen ist ja wohl nicht so weit hergeholt, oder?

Wenn das jeder so macht wirst du in arge Probleme rennen. Daher ist es schon vorprogrammiert das solch eine Lösung irgendwann Probleme bereiten wird.