nicht angemeldet
sauberes Programmieren
Nabend
Wie ruft man am Besten Funktionen auf?
Mittels function(); oder &funktion;?
Ist diese
print ($blubb." schrieb ".$bla." am ".$plopp);
oder jene
print "$blubb schrieb $bla am $plopp";
Schreibweise "schöner"?
Grüsse, Andi
-
guten Abend ebenfalls,
Wie ruft man am Besten Funktionen auf?
Mittels function(); oder &funktion;?Weder / noch. In meinen Scripts sind das Unterprogramme, die "sub Programmname()" heißen. Außerdem sind beide Notationen völlig unterschiedlich in ihrer Wirkung. Mit
sub Programmname {
...
}
schreibst du dein Unterprogramm, und mit
&Programmname;
rufst du es aus dem laufenden Script (oder aus einem anderen) heraus auf. Beispiel: http://www.christoph-schnauss.de/prog/perl/perl03.htm - unteres Drittel.Ist diese
print ($blubb." schrieb ".$bla." am ".$plopp);
oder jene
print "$blubb schrieb $bla am $plopp";
Schreibweise "schöner"?Das ist völlig wurscht, wenn es denn funktioniert. Jeder, der mit Perl arbeitet und Scripts schreibt, entwickelt mit der Zeit seine eigene Handschrift. Es gibt für Scripts auch keinen Validator (ist mir nicht bekannt) - was dir "valides" Perl bescheinigt, ist ganz einfach der Erfolg oder Mißerfolg deines Scripts. Funktioniert es, ist alles in Ordnung, funktioniert es nicht, hast du nen Problem.
Grüße aus Berlin
Christoph S.
-
Das ist völlig wurscht, wenn es denn funktioniert. Jeder, der mit Perl arbeitet und Scripts schreibt, entwickelt mit der Zeit seine eigene Handschrift. Es gibt für Scripts auch keinen Validator (ist mir nicht bekannt) - was dir "valides" Perl bescheinigt, ist ganz einfach der Erfolg oder Mißerfolg deines Scripts. Funktioniert es, ist alles in Ordnung, funktioniert es nicht, hast du nen Problem.
Guten Abend!
Das klingt ja als würden wir alle nur für einen Validator coden!
Bei HTML sichert uns der Validator in einem gewissen Rahmen zu, dass unser Code auch in einigen Jahren noch funktioniert und dass die aktuellen Browser ihn so anzeigen [sollten], wie wir es gerne hätten.
Aber ich denke schon, dass es auch bei Programmiersprachen wie Perl sehr sinnvoll ist, bestimmte Konventionen einzuhalten und "sauberen" Code zu schreiben; sei es, um ihn in einem Jahr noch ohne Probleme zu verstehen, oder ganz besonders bei der Arbeit im Team.
Natürlich gewöhnt sich dabei jeder mit der Zeit seine eigene Handschrift an, aber zu behaupten, es käme nur darauf an, dass es funktioniert ist naiv.
Deine Frage nach der schöneren Schreibweise solltest du für dich und für den Spezialfall entscheiden. Ich programmiere meistens mit Homesite und da ist es so, dassprint ($blubb." schrieb ".$bla." am ".$plopp);
in der Regel besser lesbar ist als
print "$blubb schrieb $bla am $plopp";
weil Homesite die Variablen in der ersten Version farbig hervorhebt und in der zweiten den ganzen String gleich formattiert.
Naja, für das meiste gilt jedoch schlicht und ergreifend der Grundsatz der Konsistenz.Viel Erfolg!
Robin
-
Aber ich denke schon, dass es auch bei Programmiersprachen wie Perl sehr sinnvoll ist, bestimmte Konventionen einzuhalten und "sauberen" Code zu schreiben; sei es, um ihn in einem Jahr noch ohne Probleme zu verstehen, oder ganz besonders bei der Arbeit im Team.
Hi,
Natürlich sollte jeder seine Handschrift haben, aber ein Validierer ist bei Perl nicht nötig. Bei HTML kann es sein, dass eine Site, die der IE gut anzeigt, bei Mozilla/Netscape schon seltsam wirkt und bei Opera ein Chaos ist, wegen der "tollen" "Ich-Probier-Mal-Den-Code-Zu-Korrigieren"-Taktik. Dazu ist meiner Meinung nach der Validierer da: Er stellt sicher, dass alle Browser, die die entsprechende HTML-Version unterstützen diese Site darstellen können (bzw. sollten).
Bei Perl wird jedoch, wie wir wissen, der Code - man könnte sagen - kompiliert und das Ausgabeformat ist (nicht wie Standard EXE sondern) HTML/Text. Da bei allen Perlern das Programm (hoffentlich) das gleiche ist, ist ein Validierer unnötig. Man kann ja die Syntax-Prüfung von perl.exe benutzen.
Das einzige Problem stellt hier der Unterschied zwischen Windows und Unix/Linux dar... die Compiler arbeiten relativ verschieden. Man könnte beispielsweise einen Validierer schreiben, der einen davor warnt, dass man den flock()-Befehl und Windows 9x/ME benutzen will... oder den Befehl flush() unter Windows generell... gleiches wenn man auf OLE zugreifen will, wo Linux sich gleich verabschiedet.
Sonst ist ein Validierer unnötig.
c ya,
Julian
-
hallo Julian,
ein Validierer ist bei Perl nicht nötig.
Stimmt.
Bei Perl wird jedoch, wie wir wissen, der Code - man könnte sagen - kompiliert
Stimmt nicht. Der "Code", also das Script, wird interpretiert, also Zeile für Zeiel ausgelesen und jede Zeiel wirkt als einzelner Befehl, der in Praxis umgesetzt werden soll
und das Ausgabeformat ist (nicht wie Standard EXE sondern) HTML/Text.
Wieso denn das? Das Ausgabeformat wird in den seltensten Fällen HTML sein. Nur dann, wenn ein PERL-Script dazu aufgefordert wirtd, kann es auch HTML ausgeben, das wichtigste Einsatzgebiet von PERL liegt aber auf einer ganz anderen Ebene.
Da bei allen Perlern das Programm (hoffentlich) das gleiche ist
Auch falsch - es gibt mehrere unterschiedlich alte "Programme", aktuell ist nun mal grade PERL 5.8, aber es gibt noch jede Menge ältere und sehr zuverlässig arbeitende "Programme". Man kann sich in diesem Fall auf weltweite Konformität des ausführenden Programms genausowenig verlassen wie bei den Browsern.
ist ein Validierer unnötig. Man kann ja die Syntax-Prüfung von perl.exe benutzen.
Die Begründung war verkehrt, aber die Aussage ist richtig. Nur: was machst du auf einem Rechner, auf dem es keine "perl.exe" gibt und der trotzdem PERL ausführen kann?
Das einzige Problem stellt hier der Unterschied zwischen Windows und Unix/Linux dar
Nochmals verkehrt. In der Arbeitsweise der Interpreter gibt es keinen wesentlichen Unterschied. Sie lesen ein Script aus, arbeiten es Zeile für Zeiel ab, fertig.
... die Compiler arbeiten relativ verschieden.
Eine ganz dringende Bitte: bei PERL gibt es _keinen_ Compiler. Perl ist eine interpretierende Sprache. Kompiliersprachen sind zum beispiel C/C++ und Java, aber PERL ist das eben nicht (und PHP vom Grundsatz her auch nicht).
Sonst ist ein Validierer unnötig.
Schöner Schlußsatz, sofern er auf interpretierende Sprachen angewendet wird. Für HTML gilt er nicht.
Grüße aus Berlin
Christoph S.
-
Hi,
ein Validierer ist bei Perl nicht nötig.
Stimmt.In gewisser weise ist er nötig, er ist doch in Perl eingebaut;-). In gewisser Weise kann man sagen, der Validator läuft jedes Mal, bevor das Scipt ausgeführt wird.
Bei Perl wird jedoch, wie wir wissen, der Code - man könnte sagen - kompiliert
Stimmt nicht. Der "Code", also das Script, wird interpretiert, also Zeile für Zeiel ausgelesen und jede Zeiel wirkt als einzelner Befehl, der in Praxis umgesetzt werden sollStimmt meines Wissens leider auch nicht ganz. Perl arbeitet, genau wie Java, mit einer Virtual-Machine. Sogar Larry Wall versteht Perl als einen Compiler. Das kann man unter anderem in Programmieren mit Perl nachlesen. Falls es dich interessiert, kann ich den Text mal zusammenfassen.
Eine ganz dringende Bitte: bei PERL gibt es _keinen_ Compiler. Perl ist eine interpretierende Sprache. Kompiliersprachen sind zum beispiel C/C++ und Java, aber PERL ist das eben nicht (und PHP vom Grundsatz her auch nicht).
s.o.
Grüße
Andres Freund--
ss:) zu:) ls:} fo:) de:] va:) ch:| n4:& rl:° br:^ js:( ie:% fl:( mo:|-
hallo Andres,
ein Validierer ist bei Perl nicht nötig.
Stimmt.
In gewisser weise ist er nötig, er ist doch in Perl eingebaut;-)Das kann man so nicht sagen. Es mag dir vielleicht etwas haarspalterisch vorkommen, aber das, was du bei PERL einen "Validator" nennst, ist etwas anderes als der HTML-Validator.
Dazu muß man einfach mal überlegen, was der Validator (oder die Validatoren) des W3C macht/machen: diese Software prüft bei einer zu untersuchenden Seie, ob die Anweisungen (HTML-Tags) einem bestimmten Regelwerk - der gültigen W3C-Empfehlung - entsprechen. Bei HTML ist das gar nicht so sehr viel. Was zwischen den Tags steht, also dein Seiteninhalt, wird ignoriert, und am Ende bekommst du mitgeteilt, ob du dich beim Schreiben an die gültigen Regeln gehalten hast. Dem Validator ist es egal, welcher Browser hinterher deine Seite darstellen soll.
PERL ist es keineswegs egal, wer das Script ausführt, das macht der Interpreter nämlich selber. Und es gibt ungleich mehr mögliche und durchaus "valide" Anweisungen, denk nur mal daran, was du alles mit regulären Ausdrücken machen kannst. Ein paar "Regeln" gibt es natürlich auch, zum Beispiel, daß eine Klammer, in der Argumente stehen, geschlossen werden muß. Aber du kannst beliebige Variablen verwenden, die der Interpreter unmöglich alle vorher kennen kann. Er prüft also nicht (nur), ob dein Script einem starren Satz von Regeln folgt, sondern er schaut nach, ob er deine Anweisungen Zeile für Zeile befolgen kann. Kann er das nicht, wird ein entsprechender Hinweis ausgegeben - entweder auf der Konsole oder im Protokoll (log), und die Ausführung wird abgebrochen. Ein Browser wird jedoch immer versuchen, auch fehlerhaften HTML-Code irgendwie darzustellen, er bricht seine Arbeit nicht einfach ab, da der Browser selbst nicht prüft, sondern macht, was ihm aufgetragen wird.Der "Code", also das Script, wird interpretiert, also Zeile für Zeiel ausgelesen und jede Zeiel wirkt als einzelner Befehl, der in Praxis umgesetzt werden soll
Stimmt meines Wissens leider auch nicht ganz. Perl arbeitet, genau wie Java, mit einer Virtual-Machine.Dieses "genau wie JAVA" ist nicht richtig. JAVA benötigt kompilierten Code, ähnlich wie C/C++ (von dem es sehr viel übernommen hat). Wenn du eine JAVA-Applikation entwickelst, gehst du mindestens zwei Schritte: du erstellst ein Script, das zunächst gar nichts tut. Auf Grundlage dieses Scripts und der je nach Version vorhandenen Compilerbibliotheken stellt dann der Compiler Bytecode her, mit dem dann erst die virtuelle Maschine etwas anfangen kann. Dein Script kannst du, wenn alles funktioniert hat, wegwerfen.
Anders bei PERL. Da wird eben nichts kompiliert, du schreibst dein Script, fertig. Eine virtuelle Maschine, die mit der JVM vergleichbar wäre, gibt es nicht. Was dich möglicherweise irritiert, ist, daß du häufiger was von "Präcompiler" bei PERL lesen kannst. Das bedeutet jedoch nicht, daß dein Script als Grundlage für irgendwelchen Maschinencode genommen wird, den du dann in Form eines "Programms" irgendwo abspeichern kannst. Einiges vollzieht sich, während der Interpreter arbeitet, tatsächlich im Speicher deines Rechners, dort wird etwas Maschinencode erzeugt - aber eben nicht gespeichert. Das Thema ist aber zu umfangreich, um es hier in Form von Forumsbeiträgen ein für allemal zu erklären, außerdem kannst du ein bißchen was dazu in http://selfhtml.teamone.de/cgiperl/sprache/intro.htm nachlesen.Sogar Larry Wall versteht Perl als einen Compiler. Das kann man unter anderem in Programmieren mit Perl nachlesen. Falls es dich interessiert, kann ich den Text mal zusammenfassen.
Danke, das wird aber nicht nötig sein. Dokumentationen zu PERL gibt es mehr als Sand am Meer, niemand kann alles kennen. Jeder sucht sich die Lektüre aus, die ihm am besten weiterhilft.
Da PERL schon ziemlich alt ist, hat es natürlich eine Menge Entwickler gegeben, die die eine oder andere Zutat erfunden haben. Es gibt durchaus die Möglichkeit, mit perl2exe ein kompilietres Programm herzustellen, das dann (scheinbar) ohne den Interpreter auskommt - Ähnliches gibt es auch für PHP. Diese Dinge gehören aber nicht unmittelbar zum Umfang der Sprache selbst, sondern sind zusätzliche und oft ziemlich nützliche Entwicklungen.
Grüße aus Berlin
Christoph S.
-
Hi Christoph,
Der "Code", also das Script, wird interpretiert, also Zeile für Zeiel ausgelesen und jede Zeiel wirkt als einzelner Befehl, der in Praxis umgesetzt werden soll
Stimmt meines Wissens leider auch nicht ganz. Perl arbeitet, genau wie Java, mit einer Virtual-Machine.
Dieses "genau wie JAVA" ist nicht richtig. JAVA benötigt kompilierten Code, ähnlich wie C/C++ (von dem es sehr viel übernommen hat).Der Code für Java wird doch auch nicht richtig kompiliert oder? Der wird doch auch nur in Bytecode umgewandelt? Bei Perl ist das halt kein Bytecode, sondern Opcode, der allerdings vor jedem Aufruf neu erzeugt wird.
Wenn du eine JAVA-Applikation entwickelst, gehst du mindestens zwei Schritte: du erstellst ein Script, das zunächst gar nichts tut. Auf Grundlage dieses Scripts und der je nach Version vorhandenen Compilerbibliotheken stellt dann der Compiler Bytecode her, mit dem dann erst die virtuelle Maschine etwas anfangen kann. Dein Script kannst du, wenn alles funktioniert hat, wegwerfen.
Bei Perl wird wie oben gesagt, bei jedem Aufruf Opcode erstellt, dem Äquivalent [1] zu dem Bytecode von Java. Beides enthält Anweisungen, welche C-Routine jetzt aufgerufen werden soll.
Eine virtuelle Maschine, die mit der JVM vergleichbar wäre, gibt es nicht.
Doch gibt es eben, nur wird der Bytecode (wie es bei Java doch genannt wird) vor jedem aufruf erneut erzeugt, und die VM von Java ist, anders als die von Perl, die ganze Zeit geladen. Das ist doch genau das, was Perl im Vergleich zu Java langsam macht.
Grüße Andres Freund
[1] Tut mir lLeid, dass ich mich manchmal ein wenig schwammig ausdrücke aber mir fehlen leider noch die Grundlagen, alles genauer auszudrücken, da ich das ganze (noch) nur hobbymäßig neben der Schule lerne.
--
ss:) zu:) ls:} fo:) de:] va:) ch:| n4:& rl:° br:^ js:( ie:% fl:( mo:| -
hi!
ein Validierer ist bei Perl nicht nötig.
Stimmt.
In gewisser weise ist er nötig, er ist doch in Perl eingebaut;-)
Das kann man so nicht sagen.Doch, kann man. Der Validator ist ein Programm, das anhand einer
gegebenen Grammatik (DTD) überprüft, ob ein Wort (die HTML-Datei)
in der Sprache vorkommt. Falls nicht, wird eine Warnung ausgegeben.Das ist genau das, was der Parser in Perl macht, und einen Parser gibt
es dort. Der überprüft die Syntax eines übergebenen Skriptes und
spuckt bei Nicht-Gefallen einen Syntax-Fehler aus.bye, Frank!
--
Never argue with an idiot. He will lower you to his level and then
beat you with experience.-
guten morgen ;-)
ein Validierer ist bei Perl nicht nötig.
Stimmt.
In gewisser weise ist er nötig, er ist doch in Perl eingebaut;-)
Das kann man so nicht sagen.
Doch, kann man. Der Validator ist ein Programm, das anhand einer
gegebenen Grammatik (DTD) überprüft, ob ein Wort (die HTML-Datei)
in der Sprache vorkommt. Falls nicht, wird eine Warnung ausgegeben.
Das ist genau das, was der Parser in Perl macht, und einen Parser gibt es dort.Ohje, jetzt habe ich ziemlich viele Diskussionszitate stehenlassen müssen, um den Zusammenhang zu wahren.
Du hast vollkommen recht, aber du widersprichst mir damit nicht. Ich habe prinzipiell dasselbe ausgesagt, freilich ohne das schöne Wort "Parser" zu gebrauchen, das mir grade nicht einfiel.
Wir sagen eigentlich mit geringfügig anderen Worten dasselbe aus.
Grüße aus Berlin
Christoph S.
-
-
-
-
-
-
guten Abend Robin,
Das klingt ja als würden wir alle nur für einen Validator coden!
Das ist ein völlig falscher Eindruck. Der "Validator" (es gibt viele verschiedene Mechanismen, die diesen Namen verdienen) ist lediglich ein Hilfsmittel, also "Mittel zum Zweck", niemals aber selbst "Zweck".
Bei HTML sichert uns der Validator in einem gewissen Rahmen zu, dass unser Code auch in einigen Jahren noch funktioniert und dass die aktuellen Browser ihn so anzeigen [sollten], wie wir es gerne hätten.
ACK - eigens dafür ist er auch erfunden worden.
Aber ich denke schon, dass es auch bei Programmiersprachen wie Perl sehr sinnvoll ist, bestimmte Konventionen einzuhalten und "sauberen" Code zu schreiben; sei es, um ihn in einem Jahr noch ohne Probleme zu verstehen, oder ganz besonders bei der Arbeit im Team.
Ja doch, bloß wo ist jetzt der Widerspruch zu meiner Aussage? PERL ist etwas gänzlich anderes als HTML. Man kann heute noch 20 Jahre alte PERL-Scripts vom Interpreter ausführen lassen, bei HTML ist es bereits problematisch, eine vier Jahre alte Seite in den modernen Browsern darstellen zu lassen. Und das, was ich als Beispielseite verlinkt habe, zeigt durchaus "alten" Perl-Code, wie ich ihn insgesamt heute nicht mehr schreiben würde (Verzicht auf "use:CGI", das es zur Entstehungszeit des Scripts noch nicht gab), die Stellen, um die es dem Fragesteller geht, sind aber nach wie vor gültig. Es gibt bei PERL (und bei fast allen echten Programmiersprachen) immer auch eine "Abwärtskompatibilität", die es erlaubt, auch ältere Scripts problemlos laufen zu lassen. Für HTML und die Browser gibt es so etwas nicht.
zu behaupten, es käme nur darauf an, dass es funktioniert ist naiv.
Nein, ist es bei einer echten Programmiersprache wie PERL nicht (bei einer Auszeichnungssprache wie HTML ist es das schon, weil man dann viel stärker nach dem Anzeigegerät fragen müßte)
Deine Frage nach der schöneren Schreibweise solltest du für dich und für den Spezialfall entscheiden.
Das war nicht meine Frage, sondern die von Andreas, dem ich lediglich zu antworten versucht habe.
Ich programmiere meistens mit Homesite und da ist es so, dass
print ($blubb." schrieb ".$bla." am ".$plopp);
in der Regel besser lesbar ist als
print "$blubb schrieb $bla am $plopp";
weil Homesite die Variablen in der ersten Version farbig hervorhebt und in der zweiten den ganzen String gleich formattiert.Ja, na und? Homesite ist ein Editor, aber kein Interpreter. Ob und wie Homesite Zeilen farbig markiert, ist absolut uninteressant. Der Interpreter, der die Zeilen ausführen können muß, muß verstehen, was drinsteht - Farben sind da vollkommen egal. Was für deine Augen vielleicht "schöner" aussieht, muß für den Interpreter (die "perl.exe" unter Windows) noch lange nicht bedeuten, daß er daraus einen Performance-Gewinn ziehen kann. Unter Umständen wird er durch die "Schönheit" sogar behindert. Wenn man es genau nimmt, ist die Ausgangsfrage dieses Threads sogar falsch gestellt: denn es ist völlig unerheblich, ob für unsere Augen ein Script "schön" oder auch nur "lesbar" ist. Das ausführende Programm - bei Perl also der Interpreter - soll es mit höchstmöglicher Performance und Zuverlässigkeit abarbeiten.
Christoph S.
-
-
guten Abend ebenfalls,
Wie ruft man am Besten Funktionen auf?
Mittels function(); oder &funktion;?
Weder / noch. In meinen Scripts sind das Unterprogramme, die "sub Programmname()" heißen. Außerdem sind beide Notationen völlig unterschiedlich in ihrer Wirkung.Ich weiß nicht, ob jetzt etwas falsch verstanden habe, aber meines wissens kann und sollte man auch mit "funktionsname($arg1,$arg2)" eine Funktion aufrufen.
Die Schreibweise mit &funktion(), soll meines wissens nicht mehr benutzt werden, und ist auch nur selten (symbolische Referenzen) notwendig.Grüße
Andres Freund--
ss:) zu:) ls:} fo:) de:] va:) ch:| n4:& rl:° br:^ js:( ie:% fl:( mo:|-
hallo Andres,
Ich weiß nicht, ob jetzt etwas falsch verstanden habe, aber meines wissens kann und sollte man auch mit "funktionsname($arg1,$arg2)" eine Funktion aufrufen.
Ich kann nicht einschätzen, ob du etwas falsch verstanden oder dich jetzt selber etwas schwer verständlich ausgedrückt hast. In PERL gibt es ganz einfach keine "Funktionen", die gibt es in Javascript. PERL hat dafür eben "Unterprogramme", also Subroutinen - Argumente kann man natürlich ganz nach Bedarf in den Klammerausdruck schreiben.
Die Schreibweise mit &funktion(), soll meines wissens nicht mehr benutzt werden, und ist auch nur selten (symbolische Referenzen) notwendig.
Stimmt zumindest teilweise, wenn du anstelle von "&funktion()" hier "&Programmname()" schreibst. PERL war ursprünglich (ist ja eine der ältesten Programmiersprachen) nicht objektorientiert. Heute gibt es die Möglichkeit, auch in PERL objektorientiert zu programmieren und auf Standardmodule zurückzugreifen. Ich habe bereits angedeutet, daß mein weiter oben angeführtes Scriptbeispiel (mein eigenes Gästebuch) dieser Technik noch nicht folgt. Das Schöne am Interpreter ist freilich, daß er aufgrund der "Abwärtskompatibilität" auch solche veralteten Notationsarten immer noch zuverlässig ausführt und zugleich in der Lage ist, die modernen Notationsweisen ebenso zuverlässig zu befolgen.
Grüße aus Berlin
Christoph S.
-
Hi Christoph
Ich kann nicht einschätzen, ob du etwas falsch verstanden oder dich jetzt selber etwas schwer verständlich ausgedrückt hast. In PERL gibt es ganz einfach keine "Funktionen", die gibt es in Javascript. PERL hat dafür eben "Unterprogramme", also Subroutinen - Argumente kann man natürlich ganz nach Bedarf in den Klammerausdruck schreiben.
Ist ein Unterprogramm nicht eine Funktion? Auch wenn es keine Objektorientierung gibt? Objektorientiert würde das doch Methode genannt werden, oder? So habe ich bisher zumindest gedacht. Aber ist auch nicht weiter wichtig. Was ich vorher zeigen wollte, dass man subroutinen auch mit subroutine() aufrufen kann. Ich hatte bei dir verstanden, dass das nicht möglich ist, was ein wenig ungünstig wäre, da die alte Schreibweise nicht mehr empfohlen wird.
Gute Nacht, und viel Glück beim ISO-ziehen ;-)
Andres Freund--
ss:) zu:) ls:} fo:) de:] va:) ch:| n4:& rl:° br:^ js:( ie:% fl:( mo:|-
morgens ...
Ist ein Unterprogramm nicht eine Funktion?
ups. Sehr schwer zu beantworten. Nein, es ist keinesweg dasselbe, aber es sieht so aus, als ob es dasselbe tut.
Auch wenn es keine Objektorientierung gibt?
Doch, OOP gibt es heute, mit den Zugriffsmöglichkeiten auf die zahlreichen Module, die die PERL-Entwickler inzwischen geschaffen haben.
Objektorientiert würde das doch Methode genannt werden, oder?
Vielleicht in JAVA ... wichtig ist aber nicht, wie ein Ding heißt, sondern wie es ausgeführt wird und ob es als "Objekt" wiederverwendbar ist.
Was ich vorher zeigen wollte, dass man subroutinen auch mit subroutine() aufrufen kann
Sei an solchen Stellen bitte sehr vorsichtig. In einem Forumsbeitrag wird dir mancher Schreibfehler verziehen, weil wir ja trotzdem verstehen, worum es geht, aber in einem Script gibt es kein solches Verständnis.
die alte Schreibweise nicht mehr empfohlen wird.
Zu recht. Wer heute anfängt, sollte sich gleich um die modernen Notationsarten kümmern. Wer allerdings (wie ich) berreits einen gewissen Rattenschwanz an sogenannten Erfahrungen mit sich schleppt, hat da bisweilen Probleme.
Gute Nacht, und viel Glück beim ISO-ziehen ;-)
wow, jetzt kann ich mir gar nicht vorstellen, woher du diese Information hast ... *g*
Christoph S.
-
morgens ...
Nachts ... ;-)
Ist ein Unterprogramm nicht eine Funktion?
ups. Sehr schwer zu beantworten. Nein, es ist keinesweg dasselbe, aber es sieht so aus, als ob es dasselbe tut.Was genau ist denn der Unterschied? Würd mich mal interessieren. Tut mir leid, dass ich so frage, aber soetwas interessiert mich.
Objektorientiert würde das doch Methode genannt werden, oder?
Vielleicht in JAVA ... wichtig ist aber nicht, wie ein Ding heißt, sondern wie es ausgeführt wird und ob es als "Objekt" wiederverwendbar ist.Den Begriff habe ich aus "Objektorientiert programmieren mit Perl Damian Conway", daher wird das wohl auch in Perl so genannt werden.
Sei an solchen Stellen bitte sehr vorsichtig. In einem Forumsbeitrag wird dir mancher Schreibfehler verziehen, weil wir ja trotzdem verstehen, worum es geht, aber in einem Script gibt es kein solches Verständnis.
Welches Problem sollte das hervorrufen? ob ich etwas mit &foobar(); oder foobar(); aufrufe? Ich steh jetzt vielleicht auf dem Schlauch, aber ich sehe da keine Probleme.
die alte Schreibweise nicht mehr empfohlen wird.
Zu recht. Wer heute anfängt, sollte sich gleich um die modernen Notationsarten kümmern. Wer allerdings (wie ich) berreits einen gewissen Rattenschwanz an sogenannten Erfahrungen mit sich schleppt, hat da bisweilen Probleme.Das Problem habe ich auf keinen Fall ;-)
Aber ich muss zugeben, als ich Perl gelernt habe (ist noch nicht alzulange her) habe ich auch mit &foobar() gearbeitet, da dass in dem Tutorial so gemacht wurde.wow, jetzt kann ich mir gar nicht vorstellen, woher du diese Information hast ... *g*
"Sie" sind dir immer auf den Fersen! ;-)
Andres Freund
Ps: Deine Seite funktioniert mit Opera 7.10b unter Linux auch mit aktiviertem Javascript nicht richtig.
--
ss:) zu:) ls:} fo:) de:] va:) ch:| n4:& rl:° br:^ js:( ie:% fl:( mo:|-
hehe,
Deine Seite funktioniert mit Opera 7.10b unter Linux auch mit aktiviertem Javascript nicht richtig.
Wirklich nicht? Ich habe mir die 7.10 noch nicht auf meine Linux-Installationen gezogen, mit 7.03 schien bisher alles in Ordnung. Nimm mal nen anderen Browser und nicht solches neumodisches Zeugs *g*
Christoph S.
-
Hi,
Deine Seite funktioniert mit Opera 7.10b unter Linux auch mit aktiviertem Javascript nicht richtig.
Wirklich nicht? Ich habe mir die 7.10 noch nicht auf meine Linux-Installationen gezogen, mit 7.03 schien bisher alles in Ordnung. Nimm mal nen anderen Browser und nicht solches neumodisches Zeugs *g*Lag nicht an dir, ich hab gerade Opera neugestartet und jetzt geht es. Vorher weigerte er sich die Java-Scripts bei den Links zu benutzten, jetzt geht es. (Beidemale war JS an und ich habe mehrfach neugeladen.
Grüße Andres Freund
--
ss:) zu:) ls:} fo:) de:] va:) ch:| n4:& rl:° br:^ js:( ie:% fl:( mo:|
-
-
hi!
Ist ein Unterprogramm nicht eine Funktion?
ups. Sehr schwer zu beantworten. Nein, es ist keinesweg
dasselbe, aber es sieht so aus, als ob es dasselbe tut.
Was genau ist denn der Unterschied? Würd mich mal interessieren.Eine Subroutine (= Unterpogramm) muss nicht zwingend einen Rückgabe-
wert haben, eine Funktion per Definition schon. Wenn man Perl verwendet,
ist das aber unerheblich. Das ist der einzige Unterschied.bye, Frank!
--
Never argue with an idiot. He will lower you to his level and then
beat you with experience.-
Hi Frank
Danke!
Grüße Andres Freund
--
ss:) zu:) ls:} fo:) de:] va:) ch:| n4:& rl:° br:^ js:( ie:% fl:( mo:|
-
-
-
-
-
-
-
-
Hallo Andreas,
Wie ruft man am Besten Funktionen auf?
Mittels function(); oder &funktion;?meiner Meinung nach ist das eine Geschmacksache - man sollte aber eine Schreibweise durchgängig verwenden (ich nutze &foo()).
print ($blubb." schrieb ".$bla." am ".$plopp);
oder jene
print "$blubb schrieb $bla am $plopp";
Schreibweise "schöner"?Probier doch mal
perl -e 'print (2+2)*2;'
aus :-)
Grüße,
Peter
-
Moin Moin !
http://www.perldoc.com/perl5.8.0/pod/perlstyle.html
und speziell zur &fkt; vs. fkt()-Frage:
http://www.perldoc.com/perl5.8.0/pod/perlsub.htmldaraus zitiert:
To call subroutines:NAME(LIST); # & is optional with parentheses.
NAME LIST; # Parentheses optional if predeclared/imported.
&NAME(LIST); # Circumvent prototypes.
&NAME; # Makes current @_ visible to called subroutine.&fkt; und &fkt(args) sind also Dinge, die Du in Perl 5 garantiert NICHT machen willst, außer um Dir gründlich in den Fuß zu schießen. Das sind hauptsächlich Kompatibilitätskrücken zu Perl 4.
Alexander
--
Nein, ich beantworte keine Fragen per eMail. Dafür ist das Forum da.
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so!"-
Hallo,
&fkt; und &fkt(args) sind also Dinge, die Du in Perl 5 garantiert NICHT machen willst, außer um Dir gründlich in den Fuß zu schießen.
Ich habe anfänglich meine Funktionen (äh Subroutinen) immer mit &funktion() aufgerufen, also C-typisch und mit & voran. Es war einfach als Kennzeichnung für die selbstgeschriebenen Funktionen (äh Subroutinen) nützlich. Inzwischen kenne ich den Funktionsvorat von Perl so gut, dßa ich es nicht mehr brauche, aber einen Unterschied habe ich noch nie festgestellt. Ach ja, und ich mache auch keine Parameter-Deklarationen.
Ich finde doch, daß die Diskussion über das & bei Funktionsaufrufen eher nur akademischen Wert hat. Vielleicht programmiere ich auch dementsprechend, aber wie gesagt, ich habe noch keine Situation erlebt, in der es eine Rolle gespielt hat. Ich kann mir zwar vorstellen, dßa man Fälle konstruieren kann, in denen es releavnat wird, aber wie gesagt, das ist mir dann doch zu akademisch;-)
Ist diese
print ($blubb." schrieb ".$bla." am ".$plopp);
oder jene
print "$blubb schrieb $bla am $plopp";
Schreibweise "schöner"?Ich persönlich finde zweitere besser, weil übersichtlicher. Und wenn schon erstere, dann aber nur mit Single-Quotes. Denn Double-Quotes sind in diesem Falle schlechter, da der Perlinterpreter nahc interpolierbarem Inhalt suchen muß, was bei Single-Quotes nicht der Fall ist.
Grüße
Klaus
-