Self selber verändern ... erlaubt?

[himitsu]

Erstmal ... es funktioniert.

Aber da ich grad nochmal so über Einiges nachdenk ......

In meinem himXML ist es ja nun möglich auch Node-Pfade anzugeben, was ich allerdings nachträglich implementiert und dabei nicht all zuviele am "alten" Code geändert hatte.

Im Grunde wird da am Anfang der Nodename in die Pfadbestandteile zerlegt und der aktuelle Node rausgesucht ... dann wird Self durch diesen Node ersetzt.

Heißt also es wird eine Objekt-Prozedur aufgerufen und (falls ein Nodepfad vorhanden ist) wird der Prozedur selber das eigene Objekt unterm Arsch weggezogen, dafür das andere Objekt (welcher allerdings vom selben Klassentyp ist) untergeschmugglt und dann einfach "normal" und nur mit anderen Objektdaten weitergemacht.


Also ich glaub jetzt nicht, daß ich daran jetzt wirklich nochmal was ändern werde, denn es läuft ja
(außer es finden sich wirklich große Gründe dagegen an).


Aber hat jemand damit Erfahrungen oder kann etwas zum Für und Wieder dieses Vorgehens sagen?
(ich weiß ja, daß es z.B. Probleme gibt bzw. geben kann, wenn man in einer Ereignisprozedur der VCL das eigene Objekt zu dieser Prozedur einfach so freigibt)

[mschaefer]

Die Verfahrensweise kenne ich von dem Ein / Aushängen von TreeNodes
So wie ich das sehe geht das unter Bedingungen

1: es handelt sich um Objekte einer Klasse ( ok logisch )
2. es sind keine Ereignisproceduren registriert ( hast Du beschrieben)

Letzlich kann der Compiler natürlich nicht kontrollieren was Du da machst.
Deshalb mußt Du sicherstellen, dass nie ein self mal nil wird.

Du hast damit mal wieder bewiesen, dass Du kein Eichenbrett auslässt..

Grüße // Martin

[himitsu]

Zitat von mschaefer:

Die Verfahrensweise kenne ich von dem Ein / Aushängen von TreeNodes

gut, dann bin ich wenigstens nicht der Einzige, welcher sowas macht

Zitat von mschaefer:

Du hast damit mal wieder bewiesen, dass Du kein Eichenbrett auslässt..

ich weiß, ich bin böse

nja, da ich den Code ja weitergeben möchte, wollt ich sichergehn, daß da keine all zu gefährlichen Dinge verbaut sind

[OldGrumpy]

Wie sieht das denn speichertechnisch aus, gibts da keine Lecks? Das fällt mir so spontan dazu ein...

[himitsu]

es ist praktisch so, daß die Objektfunktion mit einem Objekt aufgerufen und dann nur auf eine anderes existierendes Objekt umgebogen wird.
Beide Objekte existieren vorher und nachher.



Objekt1.Funktionsaufruf
Objekt1 auf Objekt2 umbiegen
mit Objekt2 wird nun weitergearbeitet und dieses verändert/ausgelesen

praktisch so, als wenn Objekt2.Funktionsaufruf ausgeführt worden wäre.

[himitsu]

OK, ich hatte doch einen Fehler drin ... falls meine Funktion ParseNodePath keinen passenden Node fand, setzte sie Self auf NIL und da einige Funktionen selbst im Fehlerfall das Self noch brauchten ...... nja, ist jetzt behoben und Self wird nur noch im Erfolgsfall auf ein "richtiges" Objekt abgeändert

[alzaimar]

Ist aber nicht mehr so richtig OOP, gell? Geht eher in Richtung des sog. HABDAK-Paradigmas*, das sich bei einigen Mitgliedern eines nicht näher genannten Forums, das sich auf eine eher exotisch, aber sehr charmante Programmiersprache spezialisiert hat, großer Beliebtheit erfreut..

* HABDAK = "Hacken bis der Arzt kommt"

[himitsu]

http://fnse.de/S01/0MI.gif

Zitat von alzaimar:

Ist aber nicht mehr so richtig OOP, gell?

Ich wüßte jetzt nicht wieso nicht?

Immerhin hat Borland/Codegear diesen Parameter nicht als CONST definiert, also wird man ihn doch ändern würfen?

Zitat von alzaimar:

Mitgliedern eines nicht näher genannten Forums, das sich auf eine eher exotisch, aber sehr charmante Programmiersprache ...

ich frag mich nur welches das ist http://fnse.de/S01/0AN.gif

[igel457]

Ich finde es ebenfalls nicht so schön an "self" herumzuspielen. Ich würde an deiner Stelle die betroffenen Funktionen als Klassenfunktion deklarieren und das Objekt, das bearbeitet werden soll, als Parameter übergeben.

[mschaefer]

OOP ist das schon, aber noch mit soviel Pointer
dass man es nicht einfach auf Java umsetzen kann.
Dafür muß man dann schon mit der Klasse arbeiten.
// Grüße Martin