Names for Anonymous Storage Objects 

 

Anonymous storage objects are objects that are accessed in the ABAP program indirectly through a reference, not directly through their names. They include:

• Strings
• Internal tables
• Class instances
• Anonymous data objects

Value semantics apply to the anonymous storage objects strings and internal tables so that it will suffice to enter the variable name in order to process its data content. Names for describing anonymous data objects are necessary here so that each storage object has a unique identification. If you have string sharing, for example, these names are important since several string variables can point to the same storage address

On the other hand, in the case of class instances created with the CREATE OBJECT statement and anonymous data objects created with the CREATE DATA statement, only their references in the program can be addressed.  Here reference semantics apply since the objects need to be de-referenced first in order to be able to access the data of the object concerned.

Anonymous storage objects cannot be directly addressed in the program; however, they can be addressed in the Debugger, using the following notation rules for their names.

As a rule, the names of anonymous storage objects are enclosed in curly brackets. They contain an abbreviation, together with a colon and the internal identification. The following notation rules apply to the abbreviations:

Abbrev.	Storage Object
S	Strings
T	Internal tables
O	Class instances
A	Anonymous data objects
C	Class

The internal identifications in the form x or x.y  follow after an abbreviation and colon, except in the case of classes. x stands for the object identification used internally and yfor the identification of the internal Shared Objects version. In the case of classes, the class name – instead of the identification - must be after the colon.

After the identifications, there follows an asterisk or an exclamation mark, which – however – is allowed solely for instances of classes After the exclamation mark, you have the specification of a superclass. In this way you can ensure that the object is displayed from the view of the superclass. On the other hand, the asterisk introduces a comment or additional information that is not interpreted. The following table contains contains some examples of possible identifications that are used both in the classic as well as in the new Debugger.

Name	Explanation
{S:1}	String with internal identification 1
{S:1.3}	String with internal identification 1 and internal Shared Objects version
{O:3*\CLASS=MY_CLASS}	Instance of my_class class with nterna  identification 3
{O:1!MY_SUPER_CLASS}-ATTR	Attribute attr of instance with internal identification 1 from the view of the my_super_class superclass
{C:MY_CLASS}-ATTR	Class attribute attr of my_class class