The ‘FINAL’ is here Finally…and an interesting conversation ahead !!
Curious Developer 👥: Hey Helper Bot. Anything new related to ABAP that you wanna share 🙂
Helper Bot 🤖: Hi Dev. Seems you are curious to find something new. Well I have something new for you 😊
Curious Developer 👥: Great !! What is it 🙂
Helper Bot 🤖: While writing code in ABAP, we often would like to declare immutable variables instead of mutable variables to avoid state like overwritten results or any unwanted changes
Curious Developer 👥: Certainly. But do we have something of that sort in ABAP ?
Helper Bot 🤖: Absolutely 🙂
Curious Developer 👥: Did we mean that we have something like FINAL ?
Helper Bot 🤖: Absolutely..So the FINAL operator is finally here 😊
Curious Developer 👥: Woohoo !! Can you tell me a bit more about it ?
Helper Bot 🤖: So, whenever you want a variable to be filled at exactly one write position and to be read only at all other positions, we use an immutable variable. The value cannot be changed at other write positions.
They prevent unwanted changes to the value of a variable and guarantees the consistency of the value since the last/first write access.
Curious Developer 👥: Cool !!
Helper Bot 🤖: They can be declared inline with the declaration operator FINAL of an declaration expression.
The inline declaration with FINAL works similar to the inline declaration with DATA for mutable variables.
Curious Developer 👥: Sounds good till now !!
Helper Bot 🤖: It combines the robustness of a CONSTANT with the ability to be filed at any write position with multiple write access at the same position.
Curious Developer 👥: Gotcha. But could you explain what you meant by ‘filled at exactly one write position and to be read only at all other positions’
Helper Bot 🤖: Sure. I’ll explain that. Two things to consider here regarding the write access.
- a) They can be filled at Single Write position
1 DATA: lv_name TYPE matnr VALUE '888888888888_0_1 '. 2 FINAL(lv_trim) = shift_right( val = lv_name sub = '1'). 3 "lv_trim = shift_right( val = lv_name sub = '_') <== Syntax Error / uncatchable exception MOVE_TO_LIT_NOTALLOWED_NODATA
Here immutable variable lv_trim declared using FINAL is filed at Line 2.Hence this becomes its first and last write position.
If any other position i,e at Line 3 is used for write access for the same variable, then either a syntax error or uncatchable exception MOVE_TO_LIT_NOTALLOWED_NODATA will be raised.
- b) They can be filed at Single Write position but Multiple Write access
1 LOOP AT lt_data INTO FINAL(ls_data). 2 ls_data-bedat = sy-datum. <== Syntax Error / uncatchable exception MOVE_TO_LIT_NOTALLOWED_NODATA 3 ENDLOOP.
If you are declaring an immutable variable inside a loop, similar to the above example, here you have a write position at Line 1. You can be sure that your value is stable in each loop pass. Also here at the same write position i,e Line 1, through each loop pass, different values are assigned to the variable. Hence, though we have a single write position for the same, but multiple write access is also supported in that same position.
Similar to the previous example, other position used for write access i,e at Line 2 will either raise a syntax error or uncatchable exception MOVE_TO_LIT_NOTALLOWED_NODATA.
Curious Developer👥: Wonderful.Is there any specific release from which it is available ?
Helper Bot 🤖: Yes. It is available with ABAP Release 7.89, SAP BTP ABAP Environment 2208.
Curious Developer👥: Perfect. Any other documentation or blogs that you may give as a reference
Helper Bot 🤖: Here you go:
- Keyword Documentation on Final
- ABAP Programming Guidelines
Curious Developer 👥: Awesome. That was a bit of learning for today. Waiting to come back to you soon 🙂
Helper Bot🤖:Surely. Before we end our conversation, do you know that it’s 20 years of SAP Community and on this occasion, you and your colleagues can join the #CommunitySpirit Initiative to know each other better. You can check here to know more.
Curious Developer 👥: Fabulous. I would surely like to join this initiative and help in making the community stronger. I would encourage others too. Thanks for that 😊
Helper Bot 🤖: Cheers and have a nice time 🙋♂️
I think your example of
"They can be filled at Single Write position but Multiple Write access" doesn't actually demonstrate this behaviour. This snippet does:
Count is written to several times (once per record in the internal table), but can only be written to at this position.
Thanks for the query.
I think the part of my snippet as below correctly defines that behaviour. Here ls_data is written several times at the same write position.
Could you let me know why wouldn't you consider it as multiple write access in single write position behaviour ?
Your example for FINAL(count) is also correct.
No, you're right. Your example does exhibit the same behaviour.