Functions/Methods & Return-ing Data

This may be a right silly question, but is it possible to Return more than one piece of data from a Function or Method.

For example lets assume we have just a straight forward function that returns one items of data...

Function myfunction(a)

b=5
c=a+b

Return c

End Function

print myfunction(10) ' would give us 15


But what if I wanted to return two items of data...


Function myotherfunction(a)

b=5
c=a+b
d=a-b

Return c
Return d ' how would i get this data to be returned from the function? Assuming it's possible in this way?

End Function

print myotherfunction(10) ' would give us 15

I don't know if you could return 2 values directly, but maybe you could return an array with 2 values in it. Or a string with some kind of separator in it, then parse it out. Like return 15|5 and split the string on the |.

Local c, d
myotherfunction( 10, c, d )

Print c
Print d

Function myotherfunction(a, c Var, d Var)
	Local b = 5
	c = a + b
	d = a - b
End Function

You could...
a) Return an object with fields set to the required values (for complicated returns).
b) return an array for 'like' variables.
c) Call the function with a Var ptr to the variable...

Function myotherfunction(a, c Var, d Var)

b=5
c=a+b
d=a-b

'Return c
'Return d ' how would i get this data to be returned from the function? Assuming it's possible in this way?

End Function
Local c1,d1
Print myotherfunction(10,c1,d1) ' would give us 15 
Print c1
Print d1

probably for simpler returns.

Personally I'd go with options a or b. If you're going to be passing simple datatypes by reference, you might aswell make them globals.

Hmmm, looks like I might have to have a re-think then, I was hoping it would be something straight forward I'd missed. Not to worry - thanks for the suggestions, useful all the same. :)

I might be missing something but what's not straight forward?

I don't agree with FlameDuck on this. Using c (var ptrs) is perfectly valid and allows for any proper initialized variable to be used. something globals can't do. not to mention that globals are messy and hard to keep track of.

if you do a you should be basically be doing c anyway because you shouldn't be creating a obj in the function unless the function's primary job IS to create the obj.

Yeah. Too bad it breaks encapsulation.

I'd be interested in knowing why you believe there's a semantical difference between returning a 'collector' object (like TList or TMap for instance), and returning an array object.

While I agree with your seperation of concerns concern, the way I see it, is that SOC should only ever apply to business logic objects, not helper objects. Making a string factory, for example is probably taking it a bit too far and goes against other object oriented principles like high coherency, low coupling for instance.

tonyg,

Well I need to actually try out what you suggest for one, but now I'm wondering if I even need to return more one item of data.

Also had another thought as well that might be more appropriate, but that would require me to have one method within another, i.e. to create an child of a child within an object. Again, lack of knowledge about BM and not having the software in front of me don't help! :)
Must look into this when I get home - thanks again. :)