Type Definitions and Data Declarations

New Naming Conventions

The names of class components - that is, attributes, methods, and events - can be made up of the characters "A-Z", "0-9" and "_" only. Names cannot begin with a digit.

In ABAP Objects, the following statements cause an error message:

DATA: field-name TYPE ...,
      1name TYPE ...

Correct syntax:

DATA: field_name TYPE ...,
      name1 TYPE ...

Cause:

You cannot use special characters in names, because they often have a particular meaning in the system. The new naming conventions correspond to those for other programming languages.

Cannot Use TABLES Statement

Creation of table work areas with the TABLES statement is not allowed in ABAP objects.

Error message in ABAP objects for:

TABLES dbtab.

Correct syntax:

DATA wa TYPE dbtab.

Reason:

The semantics of the TABLES statement is ambiguous.

Explicit work areas should be defined for database accesses instead of implicit table work areas.

Common interface work areas for passing data between programs and procedures are not supported in ABAP objects. In classes, only the components that a user can see are used as interface, i.e. visible attributes and the interface parameters of methods and events.

The data transport between ABAP programs and logical databases or screens via global table work areas is not allowed in ABAP objects and is replaced with other concepts.

Cannot Use the NODES Statement

You cannot create a node work area using the NODES statement in ABAP Objects.

In ABAP Objects, the following statement causes an error message:

NODES struc.

Correct syntax:

DATA wa TYPE struc.

Cause:

ABAP Objects does not support the old method of working with logical databases. Data transports between ABAP programs and logical databases using global work areas is not possible in ABAP Objects.

No common data areas

It is not allowed in ABAP Objects to create common data areas using the addition COMMON PART of the statement DATA is not allowed in ABAP Objects.

Error message in ABAP Objects if the following syntax is used:

DATA BEGIN OF COMMON PART c,
       ...
DATA END   OF COMMON PART.

Reason:

Common interface work areas for data transfer between programs and procedures are not supported in ABAP Objects. In classes only the components visible to a user are used as interfaces, i.e., visible attributes and the interface parameters of methods and events.

Cannot Use LIKEReference to Dictionary Types

In classes, you can only use a TYPE reference to data types in the ABAP Dictionary. The LIKEreference can only be used for local data objects. This also covers the attributes of the class and the data objects of the main program. In global classes, you can only make a reference to the attributes of the class. This applies to data declarations and the typing of interface parameters or field symbols.

In ABAP Objects, the following statement causes an error message:

DATA f LIKE dbtab.

Correct syntax:

DATA f TYPE dbtab.

Cause:

The TYPE addition should be the only construction that allows a reference to data types, while the LIKE addition should only be used for data objects. The Repository objects in the ABAP Dictionary are data types, not data objects. Outside the ABAP Objects context, the LIKE reference to database tables and flat structures in the ABAP Dictionary is still allowed for compatibility reasons.

Cannot Declare Type, Length, or Decimal Places Implicitly

In the TYPES statement in ABAP Objects, you must implicitly declare the type of type C types; the length of type C, N, P, and X types; and the number of decimal places of type P types.

In ABAP Objects the following statement causes an error message:

TYPES: t1,
       t2 TYPE p.

Correct syntax:

TYPES: t1(1) TYPE c,
       t2(8) TYPE p DECIMALS 0.

Cause:

Complete type definitions are a prerequisite for considering incompletely defined types as generic types later. In the DATA statement, short forms are completed as before.

Die vollständige Typdefinition ist die Voraussetzung dafür, später einmal nicht vollständig definierte Typen als generische Typen anzusehen. In der Anweisung DATA werden Kurzformen nach wie vor vervollständigt.

Incorrect Length Entry in Declaration

You cannot enter a length when typing data types D, F, I, or T in the TYPES, DATA, CLASS-DATA, STATICS or CONSTANTS statements in ABAP Objects.

In ABAP Objects, the following statement causes an error message:

DATA: f1(8) TYPE d, f2(4) TYPE i.

Correct syntax:

DATA: f1 TYPE d, f2 TYPE i.

Cause:

The inbuilt elementary data types D, F, I, and T already have predefined, unmodifiable lengths. Entering a different length is not allowed. Entering the predefined length is superfluous.

No Operational Statements in Structure Definitions

The definition of a structured data type or data object with TYPES, DATA, CLASS-DATA, STATICS and CONSTANTS may not contain any other statements in ABAP objects.

Error message in ABAP objects for:

TYPES: BEGIN OF line,
         col1 TYPE i.
MOVE 'X' TO a.
TYPES:   col2 TYPE i,
       END OF line.

Correct syntax:

TYPES: BEGIN OF line,
         col1 TYPE i,
         col2 TYPE i,
       END OF line.
MOVE 'X' TO a.

Reason:

The definition of a structure between BEGIN OF and END OF is an entire block in which only the components of the structure may be declared.

Cannot Use Anonymous Components in Structures
You cannot declare anonymous components when you define a structured data object using the DATA, CLASS-DATA, STATICS or CONSTANTS statements in ABAP Objects.

In ABAP Objects, the following statements cause an error message:

DATA: BEGIN OF struc,
        'Text Literal',
        space(10) [TYPE c],
        text(10) TYPE c VALUE 'Text Field',
      END OF struc.

Correct syntax:

DATA: BEGIN OF struc,
        text1(12)  TYPE c VALUE 'Text Literal',
        blanks(10) TYPE c VALUE IS INITIAL,
        text2(10)  TYPE c VALUE 'Text Field',
      END OF struc.

Cause:

You should be able to address each component in a structure explicitly. If you declare literals, or the special name space in the structure definition, nameless textfields are included as components. For literals, the initial and value correspond to the content of the literal. For space, the system creates a text field filled with spaces. These anonymous text fields cannot be addressed explicitly in programs. In particular, structures never contain components with the name space. You can only access anonymous components using the structure name and offset/length addressing. You can easily replace these nameless components with named components. Named components increase the function of anonymous components by allowing them to be accessed explicitly, without limiting their role as, for example, as filler fields.

Cannot Use NON-LOCAL Addition

You cannot use the NON-LOCAL addition to the DATA, STATICS, or CONSTANTS statements in ABAP Objects.

In ABAP Objects, the following statements cause a syntax error,,,,,,,,:

METHOD|FUNCTION|FORM ...
  DATA f TYPE ... NON-LOCAL.
  ...
ENDMETHOD|ENDFUNCTION|ENDFORM.

Correct syntax:

DATA f TYPE ...

METHOD|FUNCTION|FORM ...
  ...
ENDMETHOD|ENDFUNCTION|ENDFORM.

Cause:
The undocumented addition NON-LOCAL changes the attributes of a class or the local data objects of a procedure into global data objects of the main program. However, global data objects can only be defined in the main program, by their very nature. In particular, class pools cannot contain global data objects; NON-LOCAL allowed developers to get round this rule.

No definition of field groups in methods

The statement FIELD-GROUPS is not allowed in methods.

Error message in methods if the following syntax is used:

METHOD ...
  ...
  FIELD-GROUPS fg.
  ...
ENDMETHOD.

Reason:

An extract dataset currently exists only as a global object of the main program. Therefore the field groups can only be defined globally in the main program. However, the definition of the field group structure, which is generated at runtime by the statement INSERT ... INTO fg, can also be executed in methods.

FIELDS not allowed

The statement FIELDS is not allowed.

Error message in ABAP Objects if the following syntax is used:

FIELDS f.

Correct syntax:

New pseudo comment for the extended program check.

Reason:

FIELDS no longer has any operational significance but is merely used as a note for the extended program check.

Cannot Use STATICS in Instance Methods

The STATICS statement is not allowed in instance methods.

There is an error message in ABAP objects for:

METHOD ...
  STATICS s ...
  ...
ENDMETHOD.

Reason:

The STATICS statement in a method corresponds to a CLASS-DATA statement, where the visibility of the declared data objects is limited to the method. This is a potential source of misunderstanding in instance methods.