Diskussion:Perl-Programmierung

Aus Wikibooks

Wechseln zu: Navigation, Suche

Neue Beiträge bitte unten anhängen

Ältere Diskussionen werden im Perl-Archiv aufbewahrt.


Inhaltsverzeichnis

[Bearbeiten] Todo-Liste

  1. Bitte auf der Projektseite die Statusanzeiger pflegen. Ich habe die vorerst alle auf 0 gestellt --Turelion 09:07, 15. Jul. 2007 (CEST)
  2. Einige Topics sind noch gänzlich unbearbeitet. Fachleute, bitte melden!! --Turelion 09:07, 15. Jul. 2007 (CEST)
    1. Perlschnittstellen, namentlich Perl/QT, Perl/GTK, Perl/wxWidgets, mod_perl: Perl-Beschleunigung unter Apache, und die allgemeine Anleitung zu CPAN.
  3. Wie sich gezeigt hat, sind die Beispiel-Programme nicht ganz koscher, und sollten samt und sonders mal getestet werden. Anschließend sollte ein Vermerk <!-- ERFOLGREICH GETESTET --> im Seitentext direkt vor dem betreffenden Quellcode hinterlegt werden. Wer seine Programme in Wikibooks statt auf dem heimischen System entwickelt (schämt euch ;-)) sollte ab jetzt wenigstens ein <!-- NOCH NICHT ERFOLGREICH GETESTET --> voranstellen. Folgende Kapitel wurden diesbezüglich schon komplett abgearbeitet:
    1. Seiten ohne Quelltext: Vorwort, Projektdefinition, Kurzvorstellung, Das Richtige für mich, Eintauchen in die Perlenwelt, Geschichte, Larry und die Perl-Kultur, Installation.
  4. Im Buchgespräch wurde mal in einem Nebensatz vorgeschlagen, jedes Kapitel mit einer Anekdote als Einleitung auszustatten. Ist zwar keine Sache der Notwendigkeit, aber Turelion 13:58, 1. Feb. 2008 (CET) wollte es hier nochmal in Erinnerung rufen. Vielleicht erbarmt sich ja jemand. ^^

[Bearbeiten] Thematische Diskussionen

[Bearbeiten] Fallunterscheidungen

Mir ist an folgendem Progrämmchen eine Kleinigkeit an Perl aufgefallen:

#!/usr/bin/perl
 
use strict;
 
my $c=$ARGV[0];
 
if($c) {print "Wahr\n";}
else {print "Falsch\n";}

Beobachtung: "Falsch" wird ausgegeben, wenn $c==0 oder wenn $c undef ist. Sonst wird "Wahr" ausgegeben.

Das mag vielleicht nichts Waldbewegendes sein, aber Programmierfüchse finden dadurch bestimmt einen Weg, ihren Quelltext zu verkürzen und zu vereinfachen.

Könnt Ihr die Beobachtung bestätigen? Ist das wichtig genug, um im Buch erwähnt zu werden?

--Turelion 17:43, 1. Jan. 2008 (CET)

Juhu Turelion,
ich verstehe Dich nicht ganz. Ich vermute, dass Du eine Bemerkung sehen möchtest, die beschreibt, auf welche Weise man in Perl einen logisch falschen Wert aufschreiben kann. In der Tat geht das in Perl auf mannigfaltige Weise :-)
Beispiele sind 0, undef, "0" und ().
Es sollte in der Tat einen Abschnitt über Wahrheit geben. Dort sollte als Leckerli dann vermutlich auch "0 but true" erläutert werden :-D --Glauschwuffel 08:33, 3. Jan. 2008 (CET)
Hallo Glauschwuffel,
Ja, im Prinzip trifft Dein letzter Absatz es genau: Ein umfassender Abschnitt über Wahrheit/Falschheit in Perl. Ich glaube, sowas ist noch nicht da. Den Ausdruck "0 but true" finde ich klasse!!!!
Gruß, Turelion 17:22, 3. Jan. 2008 (CET)
Wo würden wir den Abschnitt ansiedeln? Das Thema ist grundlegend, sollte also vielleicht schon am Anfang auftauchen. Eventuell reicht dort aber auch eine einfache Bemerkung der Art
Alles, was nicht falsch ist, ist wahr. 0, undef und was dazu evaluiert wird, ist falsch. Mehr dazu im Abschnitt X.
Abschnitt X ist dann im zweiten Teil des Buches. Meinungen? --Glauschwuffel 08:19, 4. Jan. 2008 (CET)
Am Besten würde es IMHO hierhin passen, als Nachbemerkung oder Zusatzerläuterung oder irgendwas.
Ich glaube nicht, daß wir Einsteiger davor verschonen müssen, und ich glaube, das Thema ist nicht groß genug für einen zweiten Abschnitt. Wie gesagt, es ist nur eine Kleinigkeit.
Ich hätte es selbst schon eingebaut, aber ich habe so ein Händchen dafür, unverständlich zu erklären. Wie Du ja an meinem ersten Posting schon selbst erlebt hast!! ^^ --Turelion 19:54, 4. Jan. 2008 (CET)

[Bearbeiten] Pragmas

Hi zusammen,

unter Hello World (Stichwort Querverweise) habe ich den oben angegebenen, noch ins Leere führenden Verweis gefunden. Irgendwann könnte sich einer unserer Leser berufen fühlen, den mit Inhalt zu füllen. Von der Hauptseite führt jedoch kein Verweis dorthin.

Ich kenne mich mit Pragmas eigentlich nicht richtig aus. Sind die ein Thema für ein eigenes Kapitel? Wenn ja, wo gehört das hin? Oder sollten wir den Verweis einfach kommentarlos löschen? Die Pragmas strict und warnings werden auch in dem anderen Verweis erläutert, und wenn es dort noch an Ausgiebigkeit fehlt, sollten sie auch dort ergänzt werden. --Turelion 10:03, 1. Feb. 2008 (CET)

Moin Turelion,
das war ich :-)
Mein Idee war tatsächlich, einen Abschnitt über zumindest die gängisten Pragmata zu verfassen. Aufgrund externer Faktoren wie Hausbau und Diplomarbeit und Job bin ich dann aber natürlich nicht dazu gekommen. Es gibt eine Handvoll Pragmata (das sind ganz grob gesagt die klein geschriebenen), da kann man schon eine Menge zu schreiben. Insbesondere utf8 öffnet eine große Dose mit vielen Würmern :-)
Meinetwegen kann der Verweis erst einmal weg, dann packe ich ihn zu gegebener Zeit wieder rein. --Glauschwuffel 14:59, 12. Feb. 2008 (CET)
Ok, machen wir es so. --Turelion 21:54, 12. Feb. 2008 (CET)

[Bearbeiten] Grenzbereiche der Projektrichtlinien

Hi zusammen,

bei der Anpassung von Variablen bin ich auf einige ein- oder zweizeilige Code-Fragmente gestoßen, die trotzdem (unter der Voraussetzung, daß deren Datei von der Kommandozeile aus direkt an den Interpreter übergeben wird: perl beispieldatei.pl) alleine lauffähig wären. Kann man die so belassen? Müssen die mit Shebang und Pragmas ausgestattet werden?

Das bringt mich zu der ergänzenden Frage, ob Code-Fragmente, die NICHT alleine lauffähig sind, entsprechend gekennzeichnet werden sollten (analog zu <!--ERFOLGREICH GETESTET> zum Beispiel mit <!--CODEFRAGMENT-->, oder ob das schon wieder zuviel typisch deutscher Bürokratismus wäre.

Beste Grüße, --Turelion 10:03, 1. Feb. 2008 (CET)

Vielleicht kann man da eine kleine Vorlage basteln, die das als Hinweis für den Leser klein unter den Code schreibt? Gibt's das für andere Sprachen am Ende schon? --Glauschwuffel 15:02, 12. Feb. 2008 (CET)

[Bearbeiten] Titelbild

Hi zusammen,

Ich habe Benutzer:Philipendula gebeten, uns einen Entwurf für ein Titelbild anzufertigen. IMHO hat sie es schon mal sehr gut gemacht, möchte aber noch ein paar Ergänzungen einarbeiten. Damit Ihr schon mal einen 1. Eindruck habt:

--Turelion 17:23, 13. Feb. 2008 (CET)

[Bearbeiten] Verdeckungsregel

Welche Verdeckungsregel gilt denn in Perl oder anders gefragt: wenn ich in einem Block eine Variable deklariere, die es unter dem gleichen Namen im umgebenden Block bereits gibt, gilt dann die innere Definition im gesamten inneren Block oder erst ab der Deklaration? Ich persönlich finde, dass diese Frage im Kapitel Gültigkeitsbereich von Variablen behandelt werden sollte. --Daniel Mex 00:16, 16. Apr. 2008 (CEST)

Hallo Daniel, zunächst fühle ich mich auch ein wenig unsicher bei der Frage. Ich denke aber, daß das mit einem Skript nachprüfbar ist. Ich stelle mir ein Skript vor, daß für jeden denkbaren Einzelfall ein Perl-Programm erzeugt, startet und die von diesem erzeugten Systemmeldungen mitloggt. Jetzt müßte man sich nur noch einigen, welche Einzelfälle denkbar sind. Meine Gedanken sind zunächst folgende: Variablendeklaration kann mit 1. my, 2. our und 3. mit local geschehen. Variablendeklaration kann stattfinden im Hauptteil, in einer Unterfunktion 1. Grades (Aufruf vom Hauptteil aus.) und in einer Unterfunktion n. Grades (Aufruf von einer Unterfunktion aus). Welche Vorraussetzungen hältst Du für einen Test für sinnvoll? Hast Du noch ein paar zusätzliche zu berücksichtigende Voraussetzungen? --Turelion 20:04, 18. Apr. 2008 (CEST)
Diese Voraussetzungen erscheinen mir schon sinnvoll, ich weiß aber auch nicht, ob es noch andere Bedingungen gibt, von denen das abhängt. Interessant wäre vielleicht noch, ob für Subroutinen die gleiche Verdeckungsregel wie für Variablen gilt. --Daniel Mex 01:03, 19. Apr. 2008 (CEST)

[Bearbeiten] Testskript

#!/usr/bin/perl
#
use strict;
use warnings;
 
my @deklarationen=("local", "my", "our");
my $output="";
 
for my $top (@deklarationen) {
  for my $middle (@deklarationen) {
    for my $bottom (@deklarationen) {
      open (OUT, ">test$top$middle$bottom.pl") || die "Datei test$top$middle$bottom.pl kann nicht zum beschreiben geöffnet werden\n";
      $output=<<OUTPUT;
#!/usr/bin/perl
#
use strict;
use warnings;
 
$top \$a=1;
$top \$b=func1();
print \$a+\$b . "\n";
 
sub func1{
  $middle \$a=1;
  $middle \$b=func2();
  return \$a+\$b;
}
 
sub func2{
  $bottom \$a=1;
  $bottom \$b=2;
  return \$a+\$b;
}
 
OUTPUT
      print OUT $output;
      close(OUT);
      open (LOG, ">>declare.log") || "Log-Kommentar konnte nicht erstellt werden\n";
      print LOG "##### $top ##### $middle ##### $bottom #####\n";
      close(LOG);
      open (PIPE, "perl -f test$top$middle$bottom.pl >> declare.log 2>> declare.log|") || die "Die Log-Pipe konnte nicht gestartet werden\n";
      close (PIPE);
    }
  }  
}

Ausgabe:

 $ ./createdeklarationtestskripts.pl 
 Useless use of a constant in void context at ./createdeklarationtestskripts.pl line 38.

(Keine Ahnung, was mir die Warnung sagen soll.)

Declare.log:

##### local ##### local ##### local #####
5
##### local ##### local ##### my #####
5
##### local ##### local ##### our #####
5
##### local ##### my ##### local #####
5
##### local ##### my ##### my #####
5
##### local ##### my ##### our #####
5
##### local ##### our ##### local #####
5
##### local ##### our ##### my #####
5
##### local ##### our ##### our #####
5
##### my ##### local ##### local #####
Can't localize lexical variable $a at testmylocallocal.pl line 12.
##### my ##### local ##### my #####
Can't localize lexical variable $a at testmylocalmy.pl line 12.
##### my ##### local ##### our #####
Can't localize lexical variable $a at testmylocalour.pl line 12.
##### my ##### my ##### local #####
Can't localize lexical variable $a at testmymylocal.pl line 18.
##### my ##### my ##### my #####
5
##### my ##### my ##### our #####
5
##### my ##### our ##### local #####
Can't localize lexical variable $a at testmyourlocal.pl line 18.
##### my ##### our ##### my #####
5
##### my ##### our ##### our #####
5
##### our ##### local ##### local #####
5
##### our ##### local ##### my #####
5
##### our ##### local ##### our #####
5
##### our ##### my ##### local #####
5
##### our ##### my ##### my #####
5
##### our ##### my ##### our #####
5
##### our ##### our ##### local #####
5
##### our ##### our ##### my #####
5
##### our ##### our ##### our #####
5

Die Warnung ist tatsächlich ein bisschen seltsam. Hinter dem || Operator in der Zeile die das Log-File öffnet befindet sich nur eine Text-Konstante. Da der gesamte Ausdruck, im void-Kontext steht, warn perl davor das sie etwas nutzlos ist, da sie weder in einer Variable gespeichert wird, noch auf eine andere Art und Weise verarbeitet wird.

Die Warnung wird offensichtlich während der Übersezung generiert, da bei der Ausführung dieser Fall nicht eintritt. Falls das open Fehlschlägt würdest du es aber erst an der Warnung write to closed filehandle (kann im original abweichen) merken.

Die Verdeckungsregeln sind in perl eigentlich auch nicht schwer zu erklären. Lexikalische Variablen (mit my deklarierte) folgen dem in vielen Sprachen verwendeten Schema das eine lexikalische Variable in einem inneren Block die im äußeren Block verdeckt. mit our deklarierte Variablen verhalten sich anders, da sie ja alle ein und die selbe Variable definieren, dort hängt es vom Namensraum (package) ab und nicht von dem Block in dem sie verwendet werden. Interessant ist eigenlich nur der Sonderfall, dass lexikalische Variablen die dynamischen verdecken können, was ja nicht weiter schlimm ist. Heuzutage sollte local nicht mehr verwendet werden um Variablen zu deklarieren, da es sich wie our verhält, aber den Gültigkeitsbereich des Werts beschränkt. Das ist zwar scheinbar nur eine Konvention, meiner Meinung nach aber auch eine sinnvolle. (Ich finde die Funktionsweise von local eben so cool, dass ich es als Abwertung verstehen würde, wenn es für eine schnöde Variablendefinition eingesetzt wird.)

Zur zeit gibt es in perl keine lexikalischen Subroutinen. Sie sind wohl aber geplant und ich weiß nicht genau ob sie eventuell auch schon mit Version 5.10 implementiert wurden. Deshalb verhalten sich Subroutinen wie mit our deklarierte Variablen. Es kann pro package immer nur eine mit dem selben Namen geben. Dabei ist dann wohl eher die Reihenfolge der Ausführung auschlaggebend, als die tiefe des Blocks in dem sie sich Funktionsdefinition befindet.

happy perl hacking Giftnuss 22:14, 22. Apr. 2008 (CEST)

Zunächst mal danke für die Informationen und das Testskript. Finde ich sehr interessant. Ihr geht allerdings schon über das hinaus, was ich ursprünglich wissen wollte, nämlich ob vor der Deklaration die innere oder die äußere Definition gilt. Für our ist diese Frage nach der Erklärung hinfällig. Für local und my haben einige Tests ergeben, dass vor der Deklaration die äußere Variable gilt, was der Regel in C und C++ entspricht. Eine Ausnahme stellt der Fall dar, dass die äußere mit my und die innere mit local deklariert wurde, aber du (@Giftnuss) hast ja schon erklärt, dass local den Gültigkeitsbereich beschränkt. --Daniel Mex 01:03, 23. Apr. 2008 (CEST)
Von „http://de.wikibooks.org/wiki/Diskussion:Perl-Programmierung“
Persönliche Werkzeuge