Domino 9 und frühere Versionen > ND7: Entwicklung

Compiler-Probleme

<< < (2/2)

flaite:
Meint Composition nicht eher etwas anderes  ???
Nämlich eher die Abhängigkeit des Containers von den Teilen?
Hier liegt eher eine Abhängigkeit der Teile vom Container vor.
Werd heut abend mal in meiner Privatbibliothek nachschlagen  :)

Ich halte das für einen Fall von leaky abstraction.
Die Referenz auf das NotesDocument, mit dem das Objekt NotesItem erzeugt wurde, muß im Stack vorhanden sein, damit bestimmte Operationen durchgeführt werden können (oder so ähnlich).
Da leckt eindeutig Realität durch ein Loch der Abstraktion des Objektmodells.
Es existiert eine versteckte Abhängigkeit von bestimmten Operationen von NotesItem-Objekte auf NotesDocument, mit denen sie erzeugt wurden.   

Wenn mans weiss, ist es halb so schlimm, aber man kann das nicht wegdiskutieren.
Wo tritt das in .NET auf? Ich wüsste in verschiedenen Java/J2EE-Apis nicht wo.

Gruß Axel

animate:
Dass das eine Komposition ist, ist nur eine Theorie von mir. Das wäre die für den Hersteller günstige Erklärung. Deine Theorie kann genauso gut stimmen.

Komposition heißt in meinen Augen (und auch in denen des Autors des Beitrags auf ootips, auf den ich oben verwiesen habe), dass die Lebenszeit der einzelnen Teile vom Ganzen bestimmt wird.

Was ich mit meiner Aussage, dass das auch in anderen Sprachen vorkommt, betonen wollte, ist, dass das IMHO ein Design-"Poblem" ist und nicht Lotusscript-spezifisch.

Ich kenne auf Anhieb kein Beispiel in den JDK, oder .NET Klassen. Ich könnte mir aber vorstellen, dass das bei diversen Baumstrukturen so ist (zerstöre ich einen Knoten, werden alle Knoten darunter zerstört). Ich probiere das nachher mal aus.
Nichtsdestotrotz kannst du dir ja selber so ein Konstrukt bauen. In manchen Fällen (bei mir sehr selten, ich gebs zu) kommt es vor, dass ein Teil eben nicht ohne sein Ganzes existieren kann und dann stirbt es mit dem Ganzen.

flaite:

--- Zitat von: Thomas Völk am 24.05.06 - 07:58:58 ---Ich könnte mir aber vorstellen, dass das bei diversen Baumstrukturen so ist (zerstöre ich einen Knoten, werden alle Knoten darunter zerstört). Ich probiere das nachher mal aus.

--- Ende Zitat ---
Gravierender find ich, dass das NotesItem ja nicht zerstört wird wenn das NotesDocument zerstört wird.
Nein. Es ist noch da.
Bestimmte Operationen gehen nur anders als bevor das NotesDocument zerstört wurde.

Ich seh das auch als Design-Fehler.

Ralf_M_Petter:
Das ist ein klassisches Recycle Problem und mit ein Grund warum man in Java das manuell machen muß. Am besten man sieht sich die Problematik in Java an, dann sieht man auch was in Lotus Script passiert. Auch wenn Lotus etwas anderes behauptet bin ich der Meinung, dass Lotus script im Hintergrund das C++ API benutzt. Und im C++ API ist es halt einmal so, dass wenn man ein Objekt wie eine DB zerstört, dann werden alle abhängigen Objekte auch zerstört. Warum das manche Eigenschaften noch funktionieren, liegt meiner Meinung nach daran, dass diese im Wrapper gecached werden.

Grüße

Ralf

ZaLudtske:
Wenn man dieses Verhalten kennt ist es gut, dann kann man sich darauf einstellen und einfach nur ein Dummy-Objekt mit übergeben, das dann die Referenz auf das Vater-Objekt aufnimmt. Somit leben dann auch die gewünschten Objekte im Aufrufer weiter.

Blöd finde ich nur, dass ich bis jetzt noch nicht über dieses verhalten in der Dokumentation gefunden habe.

PS: Ich habe noch eine solche Beziehung gefunden und zwar zwischen NotesView und NotesViewEntryCollection.

Grüße

Rainer

Navigation

[0] Themen-Index

[*] Vorherige Sete

Zur normalen Ansicht wechseln