topic Re: Returning tables as value parameters in functional methods in Application Development and Automation Discussions

Returning tables as value parameters in functional methods

Former Member — Wed, 18 Nov 2009 09:09:11 GMT

Hi OO experts,

I am interested in what is a 'preferred approach' for using functional methods. Functional methods are very neat and I use them a lot for calculations or for returning single values from table read statements etc.

A returning parameter in a functional method is by VALUE.

But I see these methos also widely used in some of the ABAP OO literature for returning tables.

I would have thought that it's better to use an exporting parameter for a table since that is by REFERENCE and does not explicitly pass the data...

Is there not a performance hit incurred when using returning parameters in functional methods for tables as opposed to using exporting parameters in normal methods?

Cheers,

Gav

Re: Returning tables as value parameters in functional methods

Former Member — Thu, 19 Nov 2009 05:32:32 GMT

Hi Gavin

Yes there is a performance difference. For large internal tables, pass by reference will always give a better performance. It is strongly advised that pass by reference is used with table passing.

This link might help.

http://help.sap.com/abapdocu_70/en/ABENFORMAL_PARAMETERS_OVIEW.htm

Nandesh

Edited by: Nandesh Nair on Nov 19, 2009 6:34 AM

Edited by: Nandesh Nair on Nov 19, 2009 6:35 AM

Re: Returning tables as value parameters in functional methods

MarcinPciak — Thu, 19 Nov 2009 06:01:21 GMT

Actually we can pass a reference to a table rather than a table itself. What we need is something I described here

I really recommend sticking to using functional methods as they introduce nice way of programming and we are sure at first glance, by looking at returning parameter, what the method is responsible for (what is really calcuating at output).

Regards

Marcin

Re: Returning tables as value parameters in functional methods

Former Member — Fri, 20 Nov 2009 08:00:36 GMT

Thanks for the replies guys.