ABAP News for Release 7.40 – Bye, Bye MOVE and COMPUTE
With release 7.40 ABAP becomes extensively expression oriented. Besides the news I blogged about up to now, there are many new expression enabled operand positions, some new formatting options for string templates, and new built-in functions (e.g. ipow that can be used instead of **).
How do you write assignments in such an expression oriented world?
Clearly as
lhs = rhs.
Where rhs is
- any data object
- a functional method call
- a call of a built-in function
- an arithmetic expression
- a string expression
- a bit expression
- a constuctor expression
- a table expression
And some expression can be even lhs.
In this world there is no place for old fashioned statements MOVE and COMPUTE any more.
So it’s time to say goodbye and both are declared obsolete in the ABAP Keyword documentation
(like CALL METHOD for static method calls in Release 7.03/7.31 before).
A farewell to MOVE
You remember that one?
MOVE rhs TO lhs.
Everything you can write with MOVE you can write with the assignment operator =.
But you cannot write everything that is possible with the assignment operator with MOVE!
- You cannot MOVE constructor expressions, table expressions, arithmetic expressions, string expressions, bit expressions, and not all built-in functions.
- You cannot MOVE to LHS-expressions.
Clearly MOVE has expired …
A farewell to COMPUTE
With COMPUTE it’s another way around.
COMPUTE lhs = rhs.
You can write COMPUTE in front of each assignment with the assignment operator = and it has absolutely no effect on the statement!
You can even write
COMPUTE lhs ?= rhs.
That makes no sense!
The only assignment where COMPUTE makes sense from the literal meaning of the word is that where you have an arithmetic expression as rhs, That’s where it comes from (in stone age ABAP we had only assignments of data objects with MOVE and arithmetic calculations with COMPUTE). But nowadays it is simply superfluous to write COMPUTE in front of assignments.
Leave it away in new programs!
Couldn't agree more. I haven't used either MOVE or COMPUTE for over 10 years of ABAP programming, and I certainly won't start now.
I definitely won't miss them. 🙂
Is there some kind of code inspector check for lower releases, which would help already to avoid using these statements?
Thanks,
Peter
Don't expect too much; up to now it's only my documentation change 😈 .
Thanks for the info.
Anyway, a custom code inspector check shouldn't be a big deal for this 😉
thanks
Hi,
if move is gone - what about move-corresponding?
MOVE-CORRESPONDING is extended with Release 7.40, SP05. You can move components of internal tables now:
MOVE-CORRESPONDING [EXACT] itab1 TO itab2
[EXPANDING NESTED TABLES] [KEEPING TARGET LINES].
An new operator CORRESPONDING( ... ) is under development that covers most of the statement MOVE-CORRESPONDING and will add additional features (mapping of different component names!). Hopefully with Release 7.40, SP05 too. -> Usage of the operator will be recommended then.
I have a functional method class=>method. The return value of this method is an internal table with a column 'OBJ', that contents an object. An instance attribute of this object is a structure.
I do have an itab "target" as well, same structure as the object attribut.
loop at class=>method( ) assigning field-symbol(<source>).
append initial line to target assigning field-symbol(<target>).
move-corresponding <source>-obj->attrib to <target>.
" <source> is a line of the table, that is returned by class=>method.
" a field of this structure <source> contains an object 'OBJ', which
" has an instance attribute 'ATTRIB' which has the same structure
" like <target>.
endloop.
Because <source> und <target> do have the same declaration, I'd like to have a shorter way to append, but I do not find - even in SAP Help.
Something like:
append lines of class=>method( )-obj->attrib to target.
BUT:
append does not work, because the return value of class=>method is a table.
append lines of does not work, because class=>method( )-obj->attrib is NOT a table.
Do you have an idea for a shorter form of that LOOP?
target = VALUE #( FOR <source> IN class=>method( )
( CORRESPONDING #( <source>-obj->attrib ) ) ).
Thanks for this advice Horst Keller, i will, for now, write "=" on my expressions.
Just curious, do we have to replace our existing codes to get rid of them? Or is there a downward compatibility? Thanks
I certainly understand favoring expressions to move and compute. MOVE / COMPUTE and some other COBOL style ABAP statements never had any advantages (that I know of) compared simple expressions that have proven themselves in modern languages.
However, I do not understand recommendation to avoid CALL METHOD. CALL METHOD and CALL FUNCTION I see as one of the signature constructs of ABAP that make the language good when you have to exchange a lot of data with method and function, which is really the bread and butter for ABAP.
It is really, really neat to see what data will be passed to function/method and what data will be returned and also see which variables will be linked with which parameters at the same time.
Imagine calling CRM_ORDER_MAINTAIN in C++? What a Nightmare.
Also regarding table expressions:
While it is certainly cool you can use array like operations that ppl are used to in other languages if I understand correctly there are no performance advantages over using corresponding READ table statements.
I mean it is nice feature when you have to read table by index, but if you have to read it, just using some field, then I think I prefer READ TABLE due to readability of code and predictability of result:
Regarding CALL METHOD:
Leaving it away doesn’t change the syntax of the parameter list at all.
meth( EXPORTING … IMPORTING … CHANGING … ) .
is exactly the same as
CALL METHOD meth( EXPORTING … IMPORTING … CHANGING … ) .
Therefore, CALL METHOD is as superfluous as COMPUTE.
And using the keyword RECEIVING makes only sense for dynamic method calls, really.
result = meth( ).
instead of
CALL METHOD( RECEIVING r = result ).
Regarding table expressions:
Same as for all expressions, they show their benefit when used in operand positions.
… meth( CONV #( itab[ … ]-col ) ) …
Instead of
READ TABLE itab INTO wa.
helper = wa-col. “for conversion
meth( helper ).
What I liked about CALL METHOD is that it can be pretty printed. Such as:
When you write this in functional way, pretty print doesn't change it and you can have something like this:
Which looks pretty ugly to me. I always format these calls manually to appear like this:
I wish pretty printer could handle that.
Well, that's a flaw of the tools and not of the language.
OK, for you that difference doesn't count.
I am not saying it is flaw of language. But it is definitely an argument to use one form over the other.
The same way you can say methods are similar to forms in FM's, but the way abap editor "works" with them makes it much harder/more confusing to work with them than with methods which is why I hate them - even though given the right tools both could be efficiently used to segregate code.
In fact I think ABAP has many advantages to languages that are considered more modern - especially when it comes to readability when large complex data sets are processed and passed back and forth between processing blocks (methods, functional modules).
I see your point of view.
But from my point of view interpreting these 3 lines probably is faster and takes less skill,than interpreting that one line.
I am also not sure it is easy to understand during debugging what happens in that 1 line of code, unless you know exactly what the expressions do. Where as for these 3 lines it is easy to follow what happens step by step.
Also if you ever need to modify something in that logic my guess would be that it is more easy to do that if we start with these 3 lines. We might be able to achieve few tweaks by making that expression more complex, or even adding few more expressions, but at some point it will become quite difficult to understand what exactly is happening even if you are debugging it, much less trying to sweep by the code to get high level view.
Of course if code is performance critical and one of the forms offers performance advantages then that adds completely different dimension to this discussion.
But the way I understand this is that semantically this is almost identical and will be translated in pretty much the same statements by compiler? or ?
P.S.
I am definitely not saying expressions should not be used. In fact I like this:
meth( CONV #( itab[ … ]-col ) )
I am simply saying that readability un clarity should not be sacrificed in order to "achieve the perfect form". Above line is probably clear and improves readability and clarity by making the code more lean, but you can also easily overdo it.
Yes, but the way CALL METHOD is processed by pretty printer, makes it much more readable for methods with many parameters.
Code readability and maintainability is very very important.
Saving number of lines in code for me is not important. It is important to look at the code and understand in 5-10 seconds what does it do.
that is why I use old CALL METHOD for large calls with many parameters – especially if I need to pass many variables and receive many variables.
And that is also why I use “new syntax” for methods with few variables – especially if it has receiving variable. This is where style a = f(x). shines.