In the past you would have done something like this: DATA struct_ref TYPE REF TO data.ĪSSIGN COMPONENT 'COMP' OF STRUCTURE TO FIELD-SYMBOL(). What if the target of your reference is a structure type, which you do not know exactly at compile time? How to access the individual components of the structure? The previous paragraphs are only one part of the solution. Introducing Dynamic Reference Expressions You will still need a field-symbol of type INDEX TABLE. You can still not access variables of type DATA or ANY by index. There is however a serious limitation to this. In case that ITAB_REF does not point to a an internal table at runtime, there is the new runtime error ITAB_ILLEGAL_OPERAND. The same mechanism has been applied to internal table functions like LINES: DATA itab_ref TYPE REF TO data. It also makes it possible to directly dereference a reference and apply a table selector. READ TABLE ref->* ASSIGNING FIELD-SYMBOL() " now possible This gives many new possibilities: DATA ref TO REF TO data. You can now use variables and field-symbols of type ANY and DATA directly in LOOP and READ statements. It is also error-prone, as you might forget the error handling, which yields all kinds of funny results if you do this inside a loop and the field-symbol of the last loop iteration is still assigned. This makes the coding at least 5 lines longer, because of the error handling and the check for sy-subrc. You had to manually “reassign” the field-symbol like follows: FIELD-SYMBOLS TYPE any. Note that I am using a dynamic key specification here. In the past in many circumstances you could not use field-symbols of type ANY or variables of type DATA to access internal tables. There simply is no “ REF TO TABLE” – type. INTO TABLE however, immediately leads to a new question: The variable REF is a “REF TO DATA”, not a reference to an internal table type. Of course this also works in ABAP SQL like follows: DATA ref TYPE REF TO data. So no error handling is necessary in most cases. If FOO is the initial reference, then a runtime error will occur, as in the non-generic case. A simple example would be: DATA foo TYPE REF TO data. You can now use the dereferencing operator in most places in ABAP where you can use generically typed ABAP variables. Dereferencing generic references is now possible: (nearly) everywhere! You can have subtle bugs when the error handling is forgotten. Another disadvantage is the tricky error handling of ASSIGN. It also makes dereferencing the reference impossible inside ABAP expressions, as there is no expression variant of ASSIGN. This makes the code uglier and more difficult to read. The only possibility to access the variable “foo” would be to use field-symbols. " Syntax error: No dereferencing of generic reference possible Here and in the following the CREATE DATA statement or NEW operator has been omitted.īut when using generically typedreferences this was not possible: DATA foo TYPE REF TO data.įoo->* = 5. When using non-generic references in ABAP you always could write the following: DATA foo TYPE REF TO i. The old days: how to handle generic data references classically? Please revisit this page as it might point to the sequel in a few weeks or if new topics concerning generic programming in ABAP may arise. This is part of a series of multiple blog posts. The main mantra of the new release is: “ Get rid of field-symbols!” data types like REF TO DATA, DATA or ANY you fall back to programming style of the 70th? Then the new ABAP platform 2021 (which shipped with kernel 7.85 last week) has some new features to get you clean up your coding. New ABAP expressions for generic and dynamic programming in ABAP Platform 2021: Part I – Dynamic Access to (maybe generic) referencesĭo you use the new ABAP expressions like constructor operators or table selectors in your coding? But you often find that when using generic programming, i.e.
0 Comments
Leave a Reply. |