nicht angemeldet
Hallo CPAN,
FTP-Verzeichnis-Funktion [...] Gibt es solch eine Funktion im Padre irgendwo versteckt?
Im Changelog steht, seit Version 0.50 ist FTP dabei. Ich kann keinen Support geben, am besten fragst du die Leute selber: #padre auf dem MagNET, irc://irc.perl.org/padre
Ohauerha. Padre ist mir ein paar Mal direkt abgestürzt. Warum auch immer. Nicht gut. Auf der Suche nach Alternativen stolpere ich über Notepad++, dann stoße ich auf einen Vergleich von Notepad++ mit PSPad und in diesem Vergleich lese ich dann, daß PSPad eine Funktion namens "Code Explorer" hat. Diese Funktion zeigt alle Subs an und damit geht für mich die Sonne auf. Genau sowas habe ich mir beim Eröffnen des Threads erhofft: eine Strukturierung, mit deren Hilfe ich in etwas ausladenerem Quellcode schneller die Stelle finde, die ich suche, ohne meine Augen durch permanentes wildes Herumscrollen zu malträtieren. In manchen alten Scripten finde ich mich anhand dieses Schnell-Scroll-Bildes immer noch zurecht. Aber ich konnte mir nicht vorstellen, daß es nicht doch etwas Schlaueres gibt. Schlauer wäre in diesem Fall gewesen, sich mit dem Funktionsumfang von PSPad näher zu beschäftigen. Denn der konnte das die ganze Zeit, ich hab's nur nicht gewußt. <klatsch_an_kopf>
Richtig stattdessen ist es, Parameter immer explizit zu übergeben sowie Werte immer mit return() zurückzugeben.
Das war der Grund für das Eröffnens des anderen Threads mit dem Datenbankhandle. So soll man es tun. Zurückgeben brauche ich das Handle aber doch eigentlich nicht?
sub foo { die "I'm fooing to death!" }
foo;
Das sieht auch so schon böse aus: foo();
Wie auch immer: ich werde zukünftig 3 und 4 vertauschen. :)
> Ich habe deinen anderen Thread gelesen. Du musst wirklich OO anfangen; damit vermeidest du die überwiegenden Anzahl der Fälle, globale/geteilte Variablen benutzen zu müssen. Hole dir getrost Rat von Angesicht zu Angesicht: http://perlmongers.de/ http://conferences.yapceurope.org/gpw2010/
Danke für den Hinweis.
Auf meinem Weg zu besserem Programmierstil konnte ich bisher immer kleine Schritte gehen: das erste Mal use strict anwenden war so ein Schritt. Ich dachte bis dato, ich würde das niemals anschalten können, weil mich daraufhin tausende Fehlermeldungen überschwemmten, die ich alle nicht verstand. Ohne use strict war die Welt doch so schön einfach...
Dann kam das Buch "Perl Best Practices", für mich eine Offenbarung. Vorher lag mein Augenmerk darauf, möglichst kurzen Code zu produzieren, indem ich möglichst abgekürzte Variablennamen wie z.B. $emvorag2ohne, möglichst wenig Leerzeichen und -zeilen und überhaupt möglichst kompakte Anweisungen verwendete, das Ganze natürlich gänzlich unkommentiert. In dem Wust fand ich mich nur leider oftmals selber nicht mehr gut zurecht. In diesem Buch nun wurde mir Schritt für Schritt erklärt, wie man es \_richtig\_ macht. Genial. Genau das hatte ich gesucht.
Ein weiterer Schritt war die Verwendung von Modulen. Ich hatte immer Probleme damit, Module zu installieren. Darüber hinaus hatte ich aber noch mehr Probleme zu verstehen, wie ich die Module benutzen sollte. Die Beschreibungen im CPAN sind ja oft sehr knapp gehalten und ich hatte damals noch nie eine Referenz auf irgendwas gesetzt oder damit gearbeitet. Aber ohne Referenzen zu kennen versteht man da wirklich nicht mehr viel. Ich habe damals über die immer wiederkehrenden Sprüche über faule Perl-Programmierer, die Module benutzen, nur den Kopf schütteln können: zuerst das Ganze verwirrende Installationsgezeugsel, dann diese superknappen wirren Beschreibungen mit maximal einem kleinen Beispiel und das soll einfacher sein, als die benötigte Funktionalität eben schnell selbst zusammenzuzimmern?
Dazwischen kamen noch Datenbanken, die ich zuerst auch gemieden habe. Es geht doch auch alles mit kommaseparierten Textdateien, auf die mittels selbstgeschriebenen Lese- und Schreibroutinen zugegriffen wird. Harharhar. Das ist doch viel einfacher als sich in dieses ganze Datenbank-Verwaltungs-Einrichtungs-Neuland einzulernen. Naja, also heute sehe ich das inzwischen auch ein wenig anders - mehr noch stehe ich staunend davor, wie mithilfe von Data::Table, CGI::Formbuilder und SQL::Abstract mit lächerlich geringem Aufwand durchaus komplexe Sachen entstehen.
Der nächste Schritt wird dann wohl das Meistern von objektorientierter Programmierung sein. Tatsächlich hatte ich es mir für mein aktuelles Projekt bereits fest vorgenommen. Doch andererseits will ich ja auch vorankommen und produktiv sein. Also habe ich es vorerst zurückgestellt. Das Arbeiten mit Modulen und die Verwendung einiger erstaunlich mächtiger mySQL-Befehle waren erstmal Neuland genug.
Ich habe mir das Buch "Einführung in Perl Objekte, Referenzen und Module" (O'Reilly) schon vor längerem gekauft und gelesen. Der Groschen ist trotzdem noch nicht gefallen. Wenn ich das richtig verstehe, geht auch nur ENTWEDER ODER, also prozedual oder objektorientert programmieren? Ich verspreche mir durch OO eine noch viel stabilere Programmstruktur und einen deutlich besseren Überblick über ein Projekt. Ich glaube, daß sich die einzelnen Elemente durch OO viel besser zusammenführen lassen und sich einige der immer wiederkehrenden Würgarounds für noch eine Ausnahme und noch einen Sonderfall viel besser in die Struktur einbringen lassen.
Mir scheint jedoch, dies ist kein \_kleiner\_ Schritt. Ich muß dazu komplett umdenken, die Sache ganz anders angehen. Im Endeffekt hat es sicherlich viele Vorteile. Hast du vielleicht noch eine weitere Buchempfehlung für mich? OO für Dummies halt als eine Art Einsteigerbuch?
Besten Gruß
JOhnnY