Ich schreibe einige Methoden, HTML für verschiedene Elemente auszugeben. Jede Methode hat dieselbe Ausgabe, benötigt aber nicht unbedingt die gleiche Eingabe.
Die Methode für das Echo eines game-board muss ebenfalls ein player sein (weil jeder Spieler nur seine eigenen Teile sieht)
Das Echo eines Platinenplatzes muss nicht pro Spieler geändert werden (dieser Versand erfolgt tatsächlich in der Methode game-board , die später echo auf einem Leerzeichen aufruft). Im Idealfall wäre ich in der Lage,
Es ist auch denkbar, dass ich später auf ein Objekt stoße, das mehr als nur den Player kennen muss, um sich richtig anzeigen zu lassen. Da es bereits Methoden gibt, die auf das gleiche generische System spezialisiert sind, würde das den Fehler
ergeben %Vor% Es scheint weniger als ideal zu sein, diese Methoden echo-space , echo-board und so weiter zu benennen.
Gibt es eine kanonische Möglichkeit, andere Argumente basierend auf dem spezialisierten Objekt zu variieren? Sollte ich etwas tun wie
%Vor%oder
%Vor%? Kann mich generell jemand auf ein anständiges Tutorial zu defgeneric hinweisen? (Ich habe die entsprechenden PCL-Kapitel gelesen und einige CLOS Tutorials , aber sie decken nicht die Situation ab, die ich hier stelle).
Wenn Schnittstellen zweier Funktionen zu unterschiedlich sind, bedeutet dies, dass sie eigentlich keine Spezialisierungen der gleichen Operation sind und nicht denselben Namen haben sollten. Wenn Sie sich nur auf optionale / Schlüsselargumente spezialisieren möchten, besteht die Möglichkeit darin, eine normale Funktion zu verwenden, die eine generische Funktion aufruft und ihr Standardwerte für fehlende Argumente bereitstellt, auf die sie sich spezialisieren können.
Keenes Buch ist, glaube ich, das umfassendste Handbuch zu CLOS. Leider scheint es nur in Buchform verfügbar zu sein.
Es ist einfacher, wenn die Methoden dieselben Parameter verwenden, sich aber nur vom Datentyp unterscheiden. Aber in Fällen, in denen die allgemeine Funktion und die Methoden alle den gleichen Namen verwenden und natürlich Lambda-Listen haben, die stark variieren, tendiere ich persönlich dazu, & amp; key-Parameter zu verwenden, um meine Absichten explizit zu machen, anstatt & amp; optionale Parameter zu verwenden. Ich denke, es hilft später mit der Lesbarkeit.
Probieren Sie so etwas aus (indem wir so tun, als hätten wir bereits Klassen class-a und class-b):
%Vor%Da es sich um eine "Methodenkombination" handelt, müssen die Methodendefinitionen, um die Dispatcherlogik durch ihre möglichen Methoden zu "fließen", ähnlich einer Kette sein, in der inkompatible Lambda-Listen (dh Parameterlisten) vorkommen ) wird diese Kette brechen. Deshalb gibt es die Tasten & amp; und & amp; Erlauben-andere-Schlüssel in den Methodendefinitionen, die sie nicht speziell benötigen. Wenn wir sie in DEFGENERIC und die Methodendefinitionen einfügen, können wir die Methodendefinition haben, auf der wir basierend auf class-b versenden.
HAFTUNGSAUSSCHLUSS: Ich bin ein Common Lisp-Neuling selbst, also nimm das mit einem Körnchen Salz!
Wie sieht es mit der Neustrukturierung der Objekte / Klassen aus, so dass jedes Objekt, das Sie zurückgeben wollen, alle erforderlichen Eigenschaften in seinen eigenen (und geerbten) Slots hat?
Auf diese Weise müssen Sie sie nicht als Argumente übergeben, wenn Sie das Objekt echo aufrufen, da das, was Sie brauchen, bereits im Objekt gespeichert ist.
Tags und Links common-lisp clos