Nochmal Function: 2 Rückgaben (z.B. Array + Integer)

[TMC]

Bei einer Function reicht mir eine Rückgabe (hier: Array) nicht aus.
Zusätzlich hätte ich noch gern ein Integer - welches mir zusätzliche Auskunft gibt was in der Function passiert ist.

Gibt es überhaupt eine Möglichkeit, eine Function 2 "Werte" zurückgeben zu lassen? Oder hilft da nur ein Workaround über ein Array, in das man dann eben die Rückgabewerte schreibt?

[animate]

Simpler Type

Type person
   name as string
   age as integer
End Type

[animate]

alternative wäre

Array als Parameter byRef übergeben und in der Funktion füllen und das, was in der Funktion passiert als Rückgabewert


is wahrscheinlich geschickter

[Hernan Cortez]

... oder den Integer in den globals deklarieren, was aber etwas dreckig ist.
Globale Variablen führen wirklich oft zu Konfusion.

[TMC]

Array als Parameter byRef übergeben

Kannst Du das bitte kurz erläutern?
Sagt mir jetzt gar nichts.

Danke,
Matthias

[TMC]

... oder den Integer in den globals deklarieren, was aber etwas dreckig ist.
Globale Variablen führen wirklich oft zu Konfusion.

Hmm, stimmt, wäre auch eine Möglichkeit, danke.
Ist aber wirklich nicht sauber.

Worum es mir hier eigentlich geht:

Ich habe hier Functions, die z.B. Arrays behandeln. Hier kippe ich ein Array rein und bekomme ein behandeltes Array zurück.

Wenn das übergebene Variant z.B. kein Array ist oder leer ist (IsArray / Isempty), dann gebe ich den reingekippten Wert 1:1 wieder zurück. Schick wäre es da, zusätzlich ein Integer zu bekommen um zu sehen, wie denn die Function gelaufen ist.

[Hernan Cortez]

alternative wäre

Array als Parameter byRef übergeben und in der Funktion füllen und das, was in der Funktion passiert als Rückgabewert
is wahrscheinlich geschickter

Leicht verdribbelt, Herr Kollege.  
Variablen werden in LotusScript standardmässig by reference übergeben:

Code

Sub Click(Source As Button)
   Dim i As Integer
   Dim ar(1) As String
   ar(0) = "alt"
   ar(1) = "alt"
   Call doStuff(ar)
   For i = 0 To Ubound(ar)
      Msgbox "ar(" & Cstr(i) & ")=" & ar(i)
   Next
   
   
   
End Sub


Sub doStuff (ar As Variant)
   ar(0) = "neu"
   
End Sub

@Mathias: Das ist vielleicht die Lösung deines Problem. Du brauchst einfach den Array gar nicht zurückzugeben.
Der Funktion wird keine Kopie der Variablen übergeben (by value), sondern ein Pointer auf den Speicherbereich, wo der Inhalt der Variable steht.

Hättet ihr verdammten Zivilisten euch damals bei den Marcus Green Wochen für die Sun Certified Java Programmer certi mitgemacht, müßte das jetzt nicht mehr erklärt werden.    

Wenn die Variable im Parameter by Value (Kopie) übergeben wird, hat es keine Auswirkung, wenn die aufgerufene Funktion die Variable verändert.

Nähere Infos Notes Hilfe: "Passing arguments by reference and by value".

Gruß Axel

[TMC]

Cool, Axel, das ist ein sehr interessanter Ansatz  

Werde ich gleich mal testen.

Danke.

[TMC]

Genial  

Ich habe wohl bisher gepennt bei meinen Ansätzen.

Axel, habe gerade das Beispiel auch als Function mit Rückgabe Integer mehrmals getestet, läuft einwandfrei - habe immer auch Zugriff auf mein Array.
Dies eröffnet mir völlig neue Perspektiven für meine Functions  

Verbessertes Errorhandlig ist zusätzlich noch ein Nebenprodukt, das ich dadurch erreiche.

[Hernan Cortez]

Hab jetzt in Java für Anfänger eine neue Sektion eröffnet ("wacko practices").
http://www.atnotes.de/index.php?board=24;action=display;threadid=16065;start=0
Da wird gezeigt, wie das by reference, by value in Java läuft.

[Hernan Cortez]

Muss aber jetzt noch erwähnen, dass diese Praxis zu wirklichen Problemen führen kann, wenn jemand das Programm ändern will.
In 2 Wochen ändert jemand da einfach mal den Variablennamen und bricht somit das allgemeine Design der Funktion. Das pass_by_reference läuft dann nicht mehr.
Von solchen Praktiken wird eigentlich abgeraten und du solltest es zumindestens sehr, sehr gut im code dokumentieren.

Gruß Axel
 

[koehlerbv]

Axel, ich stimme Dir vollkommen zu. Aus langer Erfahrung ...
Mit Bezug auf Matthias' Problem folgendes:
Eine Function sollte immer einen eindeutigen Wert zurückgeben, über den die erfolgreiche Abarbeitung der Function durch das aufrufende Programm kontrolliert werden kann. Das sollte *niemals* ein referenzierter Parameter sein. Solch einer sollte nur ergänzend zu Rate gezogen, wenn ein Fehler erkannt wurde.
Welche Parameter per reference übergegen werden (was sie ja per default sind - auch das sollte man nie vergessen !), sollte dick und fett in den Routinen dokumentiert werden.

Wegen dem Default "Parameter werden per Reference übergeben" (was durchaus eigentlich sehr unsauber ist):
Wer sowas baut
Function ArraySort (vOrigArray as Variant) as Variant
darf eben nicht erarten, dass die Variable, die an vOrigArray übergeben wurde, danach noch unsortiert ist. Um sowas sauber zu handeln, müsste die function wie folgt deklariert werden:
Function ArraySort (ByVal vOrigArray as Variant) as Variant
Das kann durchaus entscheidend sein !

Meine Erfahrung:
Functions sollten eindeutig einen Erfolgs- oder Misserfolgsstatus zurückliefern.
Also entweder:
Function GetSetupDocument () As NotesDocument
- Rückgabe is  Nothing - die Sache ging in die Hose ! Das aufrufende Modul muss reagieren
oder
Function GetSetupDcoument (docSetup As NotesDocument) as Integer
- wenn diese Function False zurückgibt, war was oberfaul, andernfalls findet sich in der an docSetup übergebenen Variablen jetzt das gewünschte NotesDocument.

Das Ganze kann man natürlich um Fehlercodes / -meldungen und vieles andere ergänzen:
Function GetSetupDocument (docSetup As NotesDocument, szErrorMessage As String) as Integer
- Wenn der Rückgabewert jetzt False ist, sollte die Function in szErrorMessage gespeichert haben, was der Grund für das Scheitern war.

Das Ganze lässt sich jetzt beliebig ausbauen - nur einen eindeutigen, klaren, nachvollziehbaren roten Faden muss das Ganze haben.

HTH,
Bernhard

[animate]

Leicht verdribbelt, Herr Kollege.  
Variablen werden in LotusScript standardmässig by reference übergeben:

naja, ob das jetzt standardmäßig ist, oder nicht ist ja egal. Hauptsache by reference, oder?

[Hernan Cortez]

naja, ob das jetzt standardmäßig ist, oder nicht ist ja egal. Hauptsache by reference, oder?

Sorry: War nicht so gemeint. Ich hab das dann selbst nochmal ausprobiert und mir war gar nicht mehr präsent, dass die Variablen defaultmässig by reference übergeben werden.
Es kann schon echt nerven, wenn jemand Dinge in etwas hineininterpretiert und einen dann über Sachen belehrt, die man eh schon weiss.

@Mathias: Für eine konsistente Strategie des Austausches von Error-State-Variablen ist das sicher ok mit by Reference. Ansonsten hast du wie bei starker Nutzung von by Reference ein Variablen-Scope Problem.
Variablen-Scope ist die Sichtbarkeit der Variable. Wenn du das Beschreiben von by reference übergebenen Variablen zur gängigen Coding-Praxis machst, wird es unübersichtlich.
Global Variablen werden zumindestens immer an einer dafür vorgesehenen Stelle explizit aufgelistet.
Wenn mehrere Programme/Funktionen innerhalb eines Programmes auf 1 gemeinsame Ressource (z.B. Variable) zugreifen, steht man immer vor dem Problem, den Zugriff zu ordnen.
Vermutlich hat wg. dieser Probleme Shared Mail in Lotus Notes nie funktioniert oder in .NET sollen wohl alle Ressourcen innerhalb der Anwendung beschrieben und wohl auch getan werden. Nix mehr Registry.
Letztendlich hat das alles glaub ich eine sehr gleiche gemeinsame Ursache.
Wenn ein Programm einen Win-Registry-Eintrag macht, geht es davon aus, dass kein anderes Programm mehr diesen Registry Eintrag überschreibt.
Wenn du in der main-Funktion eine andere Funktion aufrufst und nach der Rückgabe davon ausgehst, dass die andere Funktion eine bestimmte Variable geändert hat, ist das sogar noch gefährlicher.

So ungefähr jedenfalls.

Das und vieles mehr wird übersichtlicher und klarer als ich das je könnte in dem Buch "Code Complete" von Steve McConell beschrieben. Obwohl die meisten Beispiele in Pascal sind, ist es gut lesbar. Das Thema hier z.B. S. 216 ff.
Ich kann auch Java Programmierer nicht ernst nehmen, die sich an die dort aufgeführten Gesetze nicht halten. Beliebtes Thema ist z.B. Verzicht auf Kommentierung.
-> Warum programmierst du eine Objektorientierte Sprache?
<- Das ist übersichtlicher und man kann besser ändern, erweitern und wiederverwenden.
-> Und warum setzt du keine Kommentarzeilen?
<- Keine Zeit...

Suppä.


Gruß Axel

[TMC]

Danke für Eure Infos, Anregungen und Hinweise auf die Gefahren.

Ich werde mir noch ein genaues Konzept überlegen, wie ich *durchgängig* alle Functions aufbaue.