Skip to Content

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!

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member

    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.

  2. Peter Inotai

    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?



    1. Horst Keller Post author
      • 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

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

      1. Ralf Wenzel

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


        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.


        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?

        1. Horst Keller Post author

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

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

  3. Davis Krastins

    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.




    1. Horst Keller Post author


      Regarding CALL METHOD:

      Leaving it away doesn’t change the syntax of the parameter list at all.


      is exactly the same as


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






      1. Mehmet Dagnilak

        What I liked about CALL METHOD is that it can be pretty printed. Such as:

        call method xyz
            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.


Leave a Reply