Ich habe eine Unterroutine namens debug , die ich in meinem Code verwende. Es erlaubt mir im Grunde zu sehen, was vor sich geht, usw.
Ich möchte dies prototypieren, also kann ich Folgendes tun:
%Vor%oder
%Vor%Gleichzeitig setze ich Subroutinen-Definitionen am Ende meines Programms, so dass Sie nicht 1/2 durch den Code waten müssen, um das Programm zu finden.
Ich möchte das tun:
%Vor%Ich bekomme jedoch eine Warnung, wenn ich das tue:
%Vor%Also, ich stecke fest, die Prototyp-Definition an beiden Orten zu platzieren. Was ist der richtige Weg, um so etwas zu tun?
Halt! Modulzeit - Chris Lutz
Ein Modul? Du meinst eine separate Datei erstellen? Das fügt ein wenig Komplikation hinzu, ohne das Problem zu lösen, das ich lösen möchte: Die Notwendigkeit von Klammern um diese spezielle Subroutine herum wird entfernt.
unser $ debugLevel; sollte sowieso nicht in der Unterabteilung sein, aber ich stimme Chris darin zu. - Sinan Ünür vor 3 Stunden
Die our $debugLevel muss in diesem Fall nicht da sein, aber wenn ich eine Klasse definiert habe und ich diese Subroutine in meiner Klasse zum Debuggen verwenden möchte, brauche ich sie. Ich kann es als ::debug
Überraschenderweise Viel mehr als alles, was Sie jemals über Prototypen in Perl wissen wollten , spricht das nicht an, aber ich glaube Sie können nicht vermeiden, den Prototyp an beiden Orten zu schreiben.
Ich hatte auf einen einfachen Weg gehofft, es zu vermeiden. Es gibt einen Weg, wie Eric Strom gezeigt hat. Leider ist es länger als meine Routine debug .
Früher habe ich Prototypen verwendet, aber ich habe die Angewohnheit entwickelt, keine separaten Deklarationen für Unterprogramme zu schreiben und bei allen Aufrufen Klammern zu verwenden: debug ("Ich bin in der Subroutine foo", 3); Es wurde vorgeschlagen, dass Prototypen wirklich keine gute Idee sind. TMTOWTDI - Keith Thompson 3 Stunden
Außer ich tendiere dazu zu tun:
%Vor%was beim Lesen weniger klar sein kann, und die Eingabe kann schmerzhaft sein. Immer wenn du die Klammern verdoppelst, fragst du nach Ärger. Das letzte, was ich tun möchte, ist Debugging meiner Debug-Anweisungen.
Warum willst du Prototypen? Siehe diese Frage So übergeben Sie optionale Parameter an eine Perl-Funktion - TLP
Ja, es gibt viele Probleme mit dem Prototyping. Das Hauptproblem ist, dass es einfach nicht das tut, was die Leute denken, dass es tun sollte: Deklarieren Sie die Variablentypen für die Parameter, die Sie an Ihre Funktion übergeben.
Dies ist nicht der Grund, warum ich hier Prototyping verwende.
Ich verwende selten Prototypen. Tatsächlich ist dies wahrscheinlich der einzige Fall in meinem ganzen Code, in dem ich das tue.
Der Prototyp wird an die Coderef und nicht an den Namen angehängt. Wenn Sie also die Coderef durch die neue Deklaration ersetzen, löschen Sie den Prototyp. Sie können vermeiden, dass Sie Prototypen mit einer Hilfsfunktion vergleichen und abgleichen müssen:
%Vor% install ist nur ein Wrapper um Scalar::Util s set_prototype function, mit der Sie den Prototyp einer Coderef nach der Erstellung ändern können.
Prototypen können sehr nützlich sein, aber wenn Sie den skalaren Prototyp verwenden, fragen Sie sich immer, ob das wirklich das ist, was Sie beabsichtigten. Weil der Prototyp ($;$) perl sagt "debug ist eine Funktion, die ein oder zwei Argumente annehmen kann, jedes mit einem skalaren Kontext, der der Aufrufstelle auferlegt wird".
Das bisschen über Kontext ist, wo Leute normalerweise stolpern, weil dann, wenn Sie versuchen, dies zu tun:
%Vor% Dann wird @array im skalaren Kontext gesehen und wird 2 . Der Aufruf wird also zu debug 2; anstatt zu debug 'one', 'two'; , wie Sie vielleicht erwartet haben.
Wenn ich richtig verstanden habe, möchten Sie prototypieren und vorgeben, damit Sie die Funktion (prototyped und braceless) innerhalb derselben Datei verwenden können. Das ist das subs Pragma für.
Dieser Code funktioniert beispielsweise korrekt:
%Vor%Tags und Links perl