Compiler-Probleme

[ZaLudtske]

Hallo,

ich rufe aus einer LS Prozedur eine Funktion auf. Diese wird korrekt abgearbeitet und der Rückgabewert (vom Typ NotesDocument) wird auch korrekt zu gewiesen. Sobald aber zurück in die aufrufende Prozedur gesprungen wird, verliert die aufgerufene Funktion ihren Rückgabewert.

Hat jemand eine Idee, woran es liegen könnte?

Kennt jemand ein Workaround? Der Quellcode ist syntaktische und logisch korrekt.

Rainer

[Tode]

benutz die Suche, das wurde in den letzten Wochen mindestens 3 mal diskutiert...

Tode

[koehlerbv]

Als Beispiel hier ein Thread mit Link zur Antwort.

Bernhard

[ZaLudtske]

Danke für die Hilfe.

Ich werde das nächste Mal außführlicher Suchen. Das Verhalten wundert mich trotzdem etwas. So etwas bin ich von anderen Sprachen (VB, VB.NET, C# ...) nicht gewöhnt. Dort wird ein Objekt erst dann gelöscht wenn die Referenz auf das Objekt gelöscht wird und nicht das Vater-Objekt.

Gibt es dieses Verhalten auch noch bei anderen Objekten?

Was mich wundert, ich habe eine ähnliche Prozedur bei der ich mit der PickListCollection arbeite. Dort überlebt das Document die Rückgabe an den Aufrufer.

Rainer

[animate]

Das (ähnliche) Verhalten gibts bei der Beziehung NotesDocument <-> NotesItem (s. hier.

Ich persönlich finde das sehr undurchsichtig und ich habe auch noch keine Dokumentation gesehen, die das Verhalten beschreibt/erklärt.

Ungewöhnlich ist das Verhalten aber nicht, unabhängig von der Programmiersprache. Das Konstrukt nennt sich Komposition und ist eine Spezialform einer normalen Objektbeziehung (mehr darüber hier. Das ist also kein Feature von LotusScript, sondern liegt am Design der betroffenen Klassen. Hier bedeutet das, das Datenbank-Objekt wird zerstört weil der Scope, in dem es deklariert wurde, verlassen wird, das ist ja normal. Dadurch wird der Destruktor des Objekts aufgerufen und in dem werden jetzt diverse abhängige Objekte zerstört, unabhängig davon, ob noch von wo anders drauf verwiesen wird.
Das gleiche kann dir auch in VB, VB.NET, C# ... passieren. Hat nichts mit Garbage Collection zu tun.

[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]

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.

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