clone vs. create

[githubnemo]

Im moment kann man keine Singletons (i.e. kind='singleton') instanziieren, seh ich das richtig?

clone('/base/room')

funktioniert nicht, weil room ein singleton ist. Es gibt aber keine Alternative ausser

pyclass('/base/room').create()

Die Methode mudlib.get_instance wird nie nach Aussen kommuniziert. Ich bin mir nicht sicher ob ich clone und get_instance haben wollen wuerde. Eher sowas wie clone und create. Alternativ make und clone? single?

player.environment = single('/base/room')
player.inventory = [clone('/world/muenze')]

Oder einfach was spezielles fuer Raeume (room('/base/room')), single(path) fuer generelle singletons und clone(path) fuer cloning?

player.environment = room('/base/room')
player.inventory = [clone('/world/muenze'), single('/base/mudlib_control')]

[niondir]

Ich hab noch nicht viel mit Phyton gemacht, aber dafür bin ich ja hier. Also aus meiner allgemeinen Sicht:

Nen Singleton sollte man nicht clonen können - sonst ist es keins. Gibt es keine Referenzen, dass man den Singleton Raum einfach referenziert? Ansonsten könnte man dem Raum eine UUID geben und diese der player.environment zuweisen und dann nen lookup machen wenn man drauf zugreifen muss.

Ich lass mich gerne erhellen wie man sowas in Phyton löst :)

[githubnemo]

Ansonsten könnte man dem Raum eine UUID geben und diese der player.environment zuweisen und dann nen lookup machen wenn man drauf zugreifen muss.

Das klingt gar nicht so generisch und klingt uebermaessig kompliziert wo wir doch eh schon die Infrastruktur fuer Objekte haben. Warum sollte man eine weitere Abstraktionsebene einfuehren?

Gibt es keine Referenzen, dass man den Singleton Raum einfach referenziert?

player.environment = pyclass('/base/room').create()

waere sowas, aber das ist nicht sonderlich schoen weil es a) lang und b) kompliziert ist. Daher hab ich vorgeschlagen ein Pendant zu clone zu schaffen, jetzt geht es darum ob wir sowas wollen (vermutlich ja) und wie es heissen soll: load, make, single, ...?

Ich waere fuer single, weil das zeigt das nur eine Instanz von dem Ding erzeugt wird und es mit singleton gut zusammenpasst.

Ich lass mich gerne erhellen wie man sowas in Phyton löst :)

Wie in jeder anderen OO Sprache auch. Es geht hier nicht um eine sprachagnostische Loesung sondern was am besten zur MUDLib DSL passt. Das kam vielleicht nicht so gut rueber :/

[niondir]

Dann wäre make('/base/room') nur eine factory method die intern pyclass('/base/room').create() aufruft? Dann wäre make oder create der richtige name, eher wohl create weil ja genau das getan wird :)

Ich finde aber das kind='singleton' etwas verwirrend wenn es später doch mehrere Instanzen davon geben soll. Oder übersehe ich noch etwas?

Edit: Einzelne factory methods z.B. room('/base/room') braucht man erst, wenn die create Logik nicht mehr alleine im Konstruktor stattfinden kann.

[githubnemo]

Dann wäre make('/base/room') nur eine factory method die intern pyclass('/base/room').create() aufruft? Dann wäre make oder create der richtige name, eher wohl create weil ja genau das getan wird :)

Ich find den Unterschied zwischen clone und create noch nicht so ueberzeugend weil nicht klar kommuniziert wird das bei dem einen mehrere Instanzen entstehen koennen, beim anderen aber nur immer genau eine, das muss man erst nachlesen damit man das weiss. Daher ja mein Vorschlag clone und single. Vielleicht clone und link? Beim einen erzeuge ich neues, beim anderen verweise ich auf vorhandenes?

Ich finde aber das kind='singleton' etwas verwirrend wenn es später doch mehrere Instanzen davon geben soll. Oder übersehe ich noch etwas?

Bei kind='singleton' gibt es genau eine Instanz die erzeugt wird. Die Funktion create bzw. single stellt das sicher. Das kann man dann halt in anderen Klassen ueberschreiben, also wenn man von Entity (kind=singleton) erbt, kann man in der erbenden Klasse natuerlich sagen kind=dasandere.

Einzelne factory methods z.B. room('/base/room') braucht man erst, wenn die create Logik nicht mehr alleine im Konstruktor stattfinden kann.

Seh ich nicht so. Es gibt neben dem Abstraktionsargument auch immer ein Semantik-Argument. Wenn der Haupt-Usecase das erstellen von Raeumen ist, dann ist es sinnvoll in der DSL eine Funktion zu haben die genau das tut um einen semantischen Kontext zu etablieren und die lesbarkeit vom Code zu verbessern und weniger abstrakt zu halten. Das hat auch den Vorteil, dass man - sollte es dazu kommen - eigene Logik im Nachhinein in room() einbauen kann.

[niondir]

Ich find den Unterschied zwischen clone und create noch nicht so ueberzeugend weil nicht klar kommuniziert wird das bei dem einen mehrere Instanzen entstehen koennen, beim anderen aber nur immer genau eine, das muss man erst nachlesen damit man das weiss. Daher ja mein Vorschlag clone und single. Vielleicht clone und link? Beim einen erzeuge ich neues, beim anderen verweise ich auf vorhandenes?

Okay verstehe. Also ist pyclass('/base/room').create() semantisch ein "GetInstance()". dann finde ich link('/base/room') nicht verkehrt und würde noch instance('/base/room') und get('/base/room') vorschlagen. Get ist aber eigentlich schon wieder zu generisch. Instance verbindet man eher mit singletons, daher passt das ganz gut.

Seh ich nicht so. Es gibt neben dem Abstraktionsargument auch immer ein Semantik-Argument. Wenn der Haupt-Usecase das erstellen von Raeumen ist, dann ist es sinnvoll in der DSL eine Funktion zu haben die genau das tut um einen semantischen Kontext zu etablieren und die lesbarkeit vom Code zu verbessern und weniger abstrakt zu halten. Das hat auch den Vorteil, dass man - sollte es dazu kommen - eigene Logik im Nachhinein in room() einbauen kann.

Ich bin mit DSL immer etwas vorsichtig. Am Ende gibt es dann item() aber eigentlich muss man weapon() aufrufen und fragt sich ob es auch ein container() gibt oder man es noch schreiben muss. Das bleibt dann alles an Dokumentation hängen und muss von neuen Entwicklern gelernt werden. Lieber einfach halten und mit wenigen technischen Konzepten wie clone, create und instance arbeiten.

[githubnemo]

Lieber einfach halten und mit wenigen technischen Konzepten wie clone, create und instance arbeiten.

Guter Einwand. Hat mich ueberzeugt.

Zu den Namen:

• instance('/base/room') ist zu nah an clone() dran find ich, es wird nicht suggiert dass das immer wieder die selbe Instanz ist - das selbe gilt fuer create(...)
• get('/base/room') gibt gar keine Information ueber das Verhalten und ist doch sehr generisch
• single('/base/room') gibt klar an, dass es um eine singulaere Instanz handelt, man muss aber mit der Namenskonvention 'singleton' bekannt sein damit das Sinn ergibt (denke ich)
• link('/base/room') gibt Information ueber Eindeutigkeit und ist ein gebraeuchliches Wort

Mein Favorit ist somit link('/base/room').

[niondir]

Ja, stimme ich komplett zu.

ref('/base/room') würde mir noch einfallen wenn man nahe an link bleiben will. Ist ja am Ende eine Referenz.

[githubnemo]

@kratenko Was denkst du?