When returning multiple values, how would you approach it?

[HGAutomator]

Hi,

When a function can't conveniently broken up into multiple small functions, so that passing several variables by reference would be appropriate, how would you handle it?

The choice would be passing by reference in one function ; or returning an array of the relevant values in that function.

I'm looking for 'How would you approach it?' to consider & reflection, rather than absolute advice. How would other developers deal with this type of dilemma?

I lean on the side of returning an array.

[mol]

Personally I don't like passing variables by reference.
You must make a decision by yourself.

[HGAutomator]

Yep, I know mol. I just wanted to hear what other developers are doing about it.

Personally I don't like passing variables by reference.
You must make a decision by yourself.

[edk]

The reference is Ok if the number of arguments and return values ​​is constant and not too large. When the number of returned arguments is large and/or is inconsistent, I personally use json/hash as in web solutions.

[HGAutomator]

A Hash makes sense. I forgot that Harbour has a Json contrib library.

Will think about that one, thanks edk.


The number of parameters are in the midrange, in this instance 5 of them.:

Code: Select all

CASE LastKeyPressed_n == K_RIGHT
	IF CurrentlySelectedMenuItemNumber_n < MenuItems_n
		GetMenuParametersAfterMovingRight1( Menu_a, MenuItems_n, @CurrentlySelectedMenuItemNumber_n, @FirstVisibleItemNumber_n, RowPosition_n, @ColumnPosition_n, Item_Lengths_a, @LastVisibleMenuItemNumber_n )
    	DisplayVisibleMenuItems( Menu_a, RowPosition_n, LastVisibleMenuItemNumber_n, FirstVisibleItemNumber_n )
    	DisplayReverseVideoItem( Menu_a, RowPosition_n, ColumnPosition_n, CurrentlySelectedMenuItemNumber_n )
		DisplayMessage( Messages_a, RowPosition_n+1, StartingColumnPosition_n+1, CurrentlySelectedMenuItemNumber_n )
	ELSE
		// We're at the very last menu item on the last screen, so scroll around to the very first menu on the very first screen.
  		JumpToFirstItemFirstScreen( Menu_a, MenuItems_n, RowPosition_n, @ColumnPosition_n, @CurrentlySelectedMenuItemNumber_n, @FirstVisibleItemNumber_n, @LastVisibleMenuItemNumber_n, FirstScreenLastVisibleMenuItemNumber_n )
	ENDIF

The reference is Ok if the number of arguments and return values ​​is constant and not too large. When the number of returned arguments is large and/or is inconsistent, I personally use json/hash as in web solutions.

[serge_girard]

I prefer returning an array !

Serge

[AUGE_OHR]

hi,

you can make all Variable PUBLIC ... no Parameter need to pass / return
i do NOT recommend while have "better" Solution

---

the Benefit of OOP are Member (DATA) Var which you can "read"/"Write" when need and they are "visible" in hole CLASS

HMG have "semi-OOP" ... hm ...

---

i use this Style to organize n-DIM (Instance) of CLASS TExplorer() using TAB-Control

Code: Select all

#xtranslate Menu_a         			=> Stack_Left\[nDimLeft, 1]
#xtranslate RowPosition    			=> Stack_Left\[nDimLeft, 2]
#xtranslate LastVisibleMenuItemNumber_n    	=> Stack_Left\[nDimLeft, 3]
#xtranslate FirstVisibleItemNumber_n            => Stack_Left\[nDimLeft, 4]
...
#xtranslate xReturnValue                        => Stack_Left\[nDimLeft,99]

Code: Select all

STATIC Stack_Left  := {}
STATIC nDimLeft    := 1

PROCEDURE MAIN
   AADD( Stack_Left, ARRAY( 99 ) )

all "Variable" are in 2-DIM Array
as Array is STATIC it is "visible" in hole PRG like HMG "semi-OOP"

when use a one(!) PUBLIC as Array put all #xTranslate into *.CH and include it in *.PRG where you need it

! Note : you can not use #xtranslate again as LOCAL

as you can see i have add xReturnValue so you can have "input" and "output" in same Array

[mol]

The reference is Ok if the number of arguments and return values ​​is constant and not too large. When the number of returned arguments is large and/or is inconsistent, I personally use json/hash as in web solutions.

I often use hash in my new programs/modules. It's very comfortable

[HGAutomator]

Yep, that's an interesting approach. A STATIC array would definitely do the trick.

hi,

you can make all Variable PUBLIC ... no Parameter need to pass / return
i do NOT recommend while have "better" Solution

---

the Benefit of OOP are Member (DATA) Var which you can "read"/"Write" when need and they are "visible" in hole CLASS

HMG have "semi-OOP" ... hm ...

---

i use this Style to organize n-DIM (Instance) of CLASS TExplorer() using TAB-Control

Code: Select all

#xtranslate Menu_a         			=> Stack_Left\[nDimLeft, 1]
#xtranslate RowPosition    			=> Stack_Left\[nDimLeft, 2]
#xtranslate LastVisibleMenuItemNumber_n    	=> Stack_Left\[nDimLeft, 3]
#xtranslate FirstVisibleItemNumber_n            => Stack_Left\[nDimLeft, 4]
...
#xtranslate xReturnValue                        => Stack_Left\[nDimLeft,99]

Code: Select all

STATIC Stack_Left  := {}
STATIC nDimLeft    := 1

PROCEDURE MAIN
   AADD( Stack_Left, ARRAY( 99 ) )

all "Variable" are in 2-DIM Array
as Array is STATIC it is "visible" in hole PRG like HMG "semi-OOP"

when use a one(!) PUBLIC as Array put all #xTranslate into *.CH and include it in *.PRG where you need it

! Note : you can not use #xtranslate again as LOCAL

as you can see i have add xReturnValue so you can have "input" and "output" in same Array

[franco]

I use private variables in calling program. This way they are available where ever I go from calling program. When calling program
is closed the variables are closed.
***************** ( If these variables are NOT closed with program could someone let me know.)