Skip to Content

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!

18 Comments
You must be Logged on to comment or reply to a post.
  • 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

      • Step 1: 

        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].

      • Step 2:

        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?

        • Do you have an idea for a shorter form of that LOOP?

            target = VALUE #( FOR <source> IN class=>method( )
                             ( CORRESPONDING #( <source>obj->attrib ) ) ).

  • 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:

    1. when I see read table I can quite easily predict if it will be executed in time O (1), O(log n) or O(n). It is not that easy with expression.
    2. READ TABLE emphasizes that this is internal table you are operating with, rather than just array, which is what ABAP excels at compared to other languages.
    3. Unless you have made logically certain such record exists, the code can dump when using table expression, when record does not exist. I would also argue, that using proper handling around table expression to exclude possibility of dump eliminates any advantages of “elegance” table expression might have over READ TABLE.

     

     

     

    •  

      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:

        call method xyz
          exporting
            iv_x   = lv_x
            iv_abc = lv_abc.

        When you write this in functional way, pretty print doesn’t change it and you can have something like this:

        xyz( iv_x = lv_x
          iv_abc = lv_abc ).

        Which looks pretty ugly to me. I always format these calls manually to appear like this:

        xyz( iv_x   = lv_x
             iv_abc = lv_abc ).

        I wish pretty printer could handle that.

          • 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).

             

             

      • 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 ).

        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.