Ok, ich muss zugeben, ich benutze Go nicht wirklich viel, aber ich habe gerade etwas beobachtet, was mir seltsam erscheint für eine Sprache, die nach Minimalität und all den guten Sachen strebt, wie Go es tut. Ich wäre überrascht, wenn es keine legitime Begründung dafür gibt. Das ist es, wonach ich suche.
Wenn Sie also eine Methode haben, definieren Sie sie wie folgt:
%Vor%aber warum haben Sie eine extra Parameterliste nur für den "Empfänger", wie ich denke, heißt es? Wäre es nicht einfacher und eleganter, einfach zu
zu machen %Vor% und dann muss s.Foo(5) nur in einen Aufruf einer Funktion Foo(s, 5) ?
Methoden sind grundsätzlich speziell und unterscheiden sich von regulären Funktionen.
Mit Ihrem Vorschlag wird die Grenze zwischen einer Funktion und einer Methode sehr verschwommen und es ist schwierig herauszufinden, wie die oben genannten Probleme gelöst werden können.
Ich denke, es wäre wirklich interessant, eine Sprache mit Multimethoden und Interfaces zu entwerfen. Diese Sprache wäre jedoch nicht Go.
Ihre Frage weist richtig darauf hin, dass jede Methode eine Funktion ist. Die Go-Sprache muss jedoch in der Lage sein, explizit zwischen Methoden und Funktionen zu unterscheiden. Der Grund dafür ist, dass Methoden Funktionen haben, die Funktionen nicht haben. Die Wahl, ob Foo eine Funktion oder eine Methode ist, muss vom Programmierer gemacht werden.
Go's Minimalismus bedeutet, dass die Sprache nur eine kleine Menge von Schlüsselwörtern definiert. Die Go-Autoren könnten ein neues Schlüsselwort wie method gewählt haben, um Methoden von Funktionen zu unterscheiden:
Wenn wir uns die Go-Programmiersprache ansehen, erkennen wir, dass die Philosophie darin besteht, bereits vorhandene Keywords wiederzuverwenden, anstatt für jede Gelegenheit ein eigenes Keyword zu haben. Das Schlüsselwort for ist ein gutes Beispiel für diesen Ansatz:
Die Grundidee ist, dass für den Parser (und Go-Programmierer) die verschiedenen Arten von for -Schleifen voneinander zu unterscheiden, kein neues Schlüsselwort eingeführt werden muss, wenn die Optionen durch die Syntax von what unterschieden werden können kommt nach das Schlüsselwort for : ; := range identifier ..., ihre Reihenfolge und ihre Anwesenheit / Abwesenheit.
Das Schlüsselwort func folgt demselben Muster. Es kann in mehreren Kontexten verwendet werden:
func f() {}
type F func(int) int
func (t T) SomeMethod() {}
{ ...; go func(){c<-1}(); ...}
Aus Sicht des Minimalismus ist ein einzelnes func -Schlüsselwort einfacher und eleganter als mehrere Keywords.
Die zusätzliche Parameterliste nur für den Empfänger
%Vor%ermöglicht dem Parser, Methoden und Funktionen zu unterscheiden:
%Vor% Damit kann der Parser (wie auch Go-Programmierer) unterscheiden, ob auf das func -Schlüsselwort ein Bezeichner oder auf ( folgt.
Die vorgeschlagene Ersetzung ist nicht semantisch identisch mit dem aktuellen Zustand, d. h. es handelt sich nicht nur um eine syntaktische Änderung. Es wird automatisch versucht, Methoden eines [lokalen Paket] -Typs zu erstellen, der der erste Parameter einer Funktion ist. Wenn man bedenkt, wie fundamentale Methodensätze zu Go's Konzept der automatischen Interface-Zufriedenheitsregeln gehören, wird dies sehr wahrscheinlich zu einem großen Chaos führen.
Kurz gesagt, ich denke, dass ein solcher Wechsel zur Go-Sprache nichts verbessert und gleichzeitig viele seiner schönen Funktionen in Bezug auf Methoden und Schnittstellen beschädigt.
Wahrscheinlich, weil es nicht Python ist.
Auch weil eine auf diese Weise deklarierte Funktion keine Methode ist .
Sie können keine Methode außerhalb des Objektpakets deklarieren. Ich denke also, der Hauptgrund für den Syntaxunterschied zwischen Methoden und Funktionen besteht darin, sie unterscheiden zu können.
Tags und Links go