Organisation von Klassen und Modulen auf der Festplatte (Allgemeines zu Perl)

[thread]20014[/thread]

Organisation von Klassen und Modulen auf der Festplatte

Tags: perl5 Ähnliche Threads

Leser: 13

Articles: hide open all | hide show old branches

+7 replies
der_thomas

2016-03-12 22:19

User since
2013-09-07
158 Artikel
BenutzerIn

Hallo,

ich habe eine Frage bezüglich der Ordner-, Programm-, Klassen- und Modul- Organisation auf der Festplatte.

Bei mir ist es momentan so dass ich ein Perl Verzeichnis habe, darin liegen direkt meine Perl-Scripte (.pl). Perl/
Dann gibt es darin einen Ordner names 'modules', darin sind Module (Funktionssammlungen) die nicht oop sind. Perl/modules/
Die beiden Klassen die ich bisher programmiert habe liegen jeweils auch in einem Ordner direkt im Perl Ordner. Perl/Table/ und Perl/trk_dict/
Ein weiterer Ordner 'daten' beherbergt die Datenfiles, die aber auch teilweise direkt im Perlordner liegen. Perl/daten/ und Perl/

Schön ist das alles nicht und auch wenns noch nicht viel ist, so wirds doch langsam unübersichtlich und es ist nicht konsistent - und je länger ich warte das in Ordnung zu bringen desto mehr Arbeit wirds hinterher.

Mein Ansatz wäre nun folgender:
Im Verzeichnis Perl gibt es ....
ein Verzeichnis Modul oder Modules - darin befinden sich weitere Verzeichnise, jeweils eines für jedes Modul, z.B. Algo_Tool.pm, Algo_Tool.html (pod)
ein Verzeichnis Class oder Classes - darin befinden sich weitere Verzeichnise, jeweils eines für jede Klasse, in denen dann die class.pm liegt
pro Programm ein Verzeichnis, darin dann direkt z.B. 'laufen.pl' und ein weiteres Verzeichnis 'daten' mit den datenfiles

Ist das euerer Meinung nach so sinnvoll, oder was hat sich in der Praxis bewährt oder was würdet ihr empfehlen ?

Alternativ könnte man Klassen und Module auch in ein Verzeichnis tun, oder auch alle Datenfiles in einem zentralen Verzeichnis ablegen ... ???

MfG
Thomas
- +2 replies
- hlubenow
  
  2016-03-13 00:31
  
  User since
  2009-02-22
  875 Artikel
  BenutzerIn
  
  Ich schätze mal, Module sollten in
  
  /usr/lib/perl/site_perl
  
  liegen, Skripte z.B. in "/usr/local/bin".
  - der_thomas
    
    2016-03-13 18:53
    
    User since
    2013-09-07
    158 Artikel
    BenutzerIn
    
    Da niemand anders was anderes sagt (Das von janus scheint ja eher eine Detailantwort zu sein), ist das wohl die Standardvorgehensweise ?
    
    Scheint auch konsistent dazu zu sein wie Scripte und Module sonst gespeichert werden. Vor allem wenn ich die Nutzerdaten (Datenfiles) im Homeverzeichnis belasse.
    
    Was mir daran noch nicht gefällt ist:
    -Dass ich Geany jedesmal mit Rootrechten starten muss, wenn ich was ändern will.
    -Wenn ich eine neue Mint/Ubuntu Version installiere jedesmal das Ganze wieder einbinden muß (gut, da könnte man sich ein Script schreiben dass das automatisiert). Bisher ist es so dass ich nach eine Installation nur das externe Homeverzeichnis mounten und ein paar Perl Module aus CPAN nachinstallieren muss - und alles ist wieder so wie es war.
    -Das Installieren auf einen anderen Rechner wäre auch mit dem Kopieren meines Perl Verzeichnises getan.
    -Ein Backup meines gesamten 'Perlzeugs' wäre aufwändiger.
    
    Bin noch unschlüssig, daher nochmal die Frage: Spricht was gegen meinen Ansatz, außer dass es vielleicht nicht dem üblichen Weg entspricht ?
- +4 replies
- Gast janus
  
  2016-03-13 11:50
  
  http://perl.rolfrost.de/class.html
  Last edited: 2016-03-13 13:22:30 +0100 (CET)
  - +3 replies
  - pq
    
    2016-03-13 13:36
    
    User since
    2003-08-04
    12208 Artikel
    Admin1
    
    Quote
    use Foo;
    
    Die Datei Foo.pm muss sich in einem Verzeichnis befinden, welches namentlich auch im @INC Pfad eingetragen ist. Gleichermaßen muss innerhalb der Datei package Foo; notiert sein.
    
    Falsch. Es ist unerheblich, ob in Foo.pm ein package-statement steht, und welcher package-name es ist. Damit use Foo; funktioniert, muss das Ding nur kompilieren und einen wahren Wert zurückliefern.
    Will man objektorientiert arbeiten, wird der Packagename wichtig, ja.
    
    Quote
    Merke: Das @INC Array lässt sich mit use lib qw(/home /user); manipulieren. Dieses Pragma stellt sicher, dass ein Verzeichnispfad nur einmal im Array eingetragen wird.
    
    Diese Aussage (nur einmal eingetragen) ist doch hier nur verwirrend. Hättest du ausführlich die manuelle Manipulation von @INC erklärt, wäre das erwähnenswert. Aber der wichtigere Unterschied, der dann zu erwähnen wäre, ist, dass man mittels "use lib" @INC zur compile time ändert, während man bei manueller Manipulation von @INC einen BEGIN-block schreiben muss (oder alternativ das Modul zur Laufzeit laden muss).
    
    Quote
    Des Weiteren wird mit der Package-Deklaration package Foo::Bar; ausgedrückt, dass Bar eine Klasse ist, die von Foo erbt.
    
    Das ist einfach nur falsch. Es gibt keinen Automatismuss, wonach Foo::Bar von Foo erbt.
    
    Du erwähnst oben "use Modulname" und "use lib". In deinem Beispiel unten schreibst du aber das eigentliche Skript mit in die Moduldatei, wodurch "use Number" und auch "use lib" unnötig wird.
    Das ist aber in der Praxis später selten sinnvoll.
    
    Aber wozu dann überhaupt die Erwähnung oben, wenn du es im Beispiel gar nicht anwendest?
    Last edited: 2016-03-13 13:38:19 +0100 (CET)
    Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
    lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
    - +2 replies
    - Gast janus
      
      2016-03-13 14:14
      
      Quote
      Du erwähnst oben "use Modulname" und "use lib". In deinem Beispiel unten schreibst du aber das eigentliche Skript mit in die Moduldatei, wodurch "use Number" und auch "use lib" unnötig wird.
      Das ist aber in der Praxis später selten sinnvoll.
      
      In der Praxis entwickle ich meine Module so, dass der Code zum Testen innerhalb derselben Datei steht und später infolge __END__ Token abgetrennt wird. Das hat sich tausendfach bewährt, ebenso bleibt der Testcode auch in der Datei stehen für Später.
      
      Das sind aber alles Dinge die Du neben anderen Artikeln, basierend auf nunmehr 20jährigen Erfahrungen im praktischen Programmieren mit Perl, allesamt auf meinen Seiten nachlesen kannst.
      
      Also bitte alles lesen und die Dinge nicht aus dem Zusammenhang reißen.
      Last edited: 2016-03-13 14:21:16 +0100 (CET)
      - Muffi
        
        2016-03-14 10:05
        
        User since
        2012-07-18
        1465 Artikel
        BenutzerIn
        
        Erzähl doch mal allen noch mal wie viele Jahre du nun schon Programmiererfahrung hast. Ich glaub ich habs zwar schon 10 mal gelesen, aber ich kann mich nicht sattlesen davon.
        Vor allem bis du wohl einer von ganz wenigen, wenn nicht der Einzige weltweit, der sowas vorweisen kann.
        1 + 1 = 10

View all threads created 2016-03-12 22:19.