Skip to content

ABAP Keyword Documentation →  ABAP − Release-Specific Changes →  Changes in Release 6.10 

ABAP Objects in Release 6.10


1. Dynamic access: Accessing object attributes dynamically


2. CALL METHOD optional when calling methods


3. Friends- friendship between classes


4. New additions available when implementing interfaces


5. Parameter transfer when dynamically instantiating


6. OO transactions

7. Enhanced syntax for interfaces

8. Enhanced syntax for event handling


9. Enhanced syntax for the instance constructor of subclasses


10. Dynamically accessing interface constants

Other versions: 7.31 | 7.40 | 7.54

Modification 1

Dynamic access: Accessing object attributes dynamically

The following variants of the dynamic ASSIGN statement allow you to access the attributes of classes dynamically.

  • assign oref->(f) to <fs>.
  • assign iref->(f) to <fs>.
  • assign (f1)=>(f2) to <fs>.
  • assign c=>(f) to <fs>.
  • assign (f)=>f to <fs>.

The attribute search is first carried out in the static type. If the search was unsuccessful or the attributes were not visible in the context, then the system searches the dynamic type.

Modification 2

CALL METHOD optional when calling methods

In static method calls of the form CALL METHOD meth( ), the CALL METHOD expression is optional. Instead, it is now sufficient to write meth( ).

Modification 3

Friends- friendship between classes

With the Friends concept, a class can offer friendship to other classes or interfaces, GLOBAL FRIENDS and LOCAL FRIENDS being possibilities. These friends can then access all the components of the provider class, and can always instantiate the class. The PROTECTED and PRIVATE components are always PUBLIC to friends. Classes offer friendship to other classes or interfaces using the FRIENDS addition to the CLASS ... DEFINITION statement. The new concept makes the previous language construction DATA TYPE REF TO class %_friend obsolete.

Modification 4

New additions available when implementing interfaces

The INTERFACES statement has the new additions ABSTRACT | FINAL METHODS and ALL METHODS ABSTRACT | FINAL, which allow you to make methods in the implementing class abstract or final. A further addition is DATA VALUES, which assigns start values to interface attributes when you implement within a class.

Modification 5

Parameter transfer when dynamically instantiating

CREATE OBJECT (class)

Modification 6

OO transactions

In Transaction Maintenance, you can classify a transaction code as an OO transaction. The transaction code is then linked, either to the Transaction Service of the ABAP - Object Services for persistent objects, or to any method of a global or local class of a program. When such a transaction is called, the system loads the program associated with the class, generates an object using an instance method, and executes the method.

Modification 7

Enhanced syntax for interfaces

All the component interfaces of a compound interface are treated equally in the interface and in the implementing class. This means that you can now access the components of inner interfaces directly using interface references. Previously, this was only possible using class reference variables. 

INTERFACE i1. 
  DATA a1. 
ENDINTERFACE. 

INTERFACE i2. 
  INTERFACES i1. 
  data A2 like I1~A1. 
ENDINTERFACE. 

DATA iref TYPE REF TO i2. 

WRITE iref->i1~a1.

In previous releases this example would have caused a syntax error with the expressions containing i1~a1 and you would have had to use aliases. Nonetheless, in Release 6.10 you should only use the interface component selector (~) outside classes or interfaces in exceptional circumstances.

Modification 8

Enhanced syntax for event handling

In the SET HANDLER statement, the system now checks the precise type of the reference variable that points to a triggering object. The type must be of the same class or subclass as the one listed in the declaration of event handlers as METHODS after FOR EVENT evt OF. Thus, you cannot register objects of superclasses, even if the event has been inherited from that superclass. If an interface has been declared after FOR EVENT evt OF, the type of the reference variable must be of the type of the interface itself; or of a class or subclass that implements the interface; or another interface that contains the interface as a component.

From Release 6.10 onward, the type of the implicit event parameter sender, which can be imported by a handler method and transferred using RAISE EVENT, is determined using the class or interface that is listed in the declaration of the event handler after the FOR EVENT OF addition of the METHODS statement. In previous releases, the type was determined by the class or interface in which - using EVENTS - the event was declared.

Modification 9

Enhanced syntax for the instance constructor of subclasses

In the instance constructor of subclasses you must always call the constructor of the superclass using [CALL METHOD] super->constructor, even if this superclass was not explicitly defined there. Direct subclasses of the root class OBJECT are the only exception. As a result, you can later implement instance constructors in superclasses, without invalidating the subclasses. As from Release 6.10, the following program causes a syntax warning without calling the superclass constructor: 

CLASS c1 DEFINITION INHERITING FROM object. 
  PUBLIC SECTION. 
    ... 
ENDCLASS. 

CLASS c1 IMPLEMENTATION. 

ENDCLASS. 

CLASS c2 DEFINITION INHERITING FROM c1. 
  PUBLIC SECTION. 
    METHODS constructor. 
ENDCLASS. 

CLASS c2 IMPLEMENTATION. 
  METHOD constructor. 
    ... 
    super->constructor( ) 
    ... 
  ENDMETHOD. 
ENDCLASS.

Modification 10

Dynamically accessing interface constants

You can now dynamically access interface constants using INTF=>KONST. In order to enable this, the logic for dynamic ASSIGN, dynamic access, and dynamic invoke has been changed in such a way that global classes are now obscured by local types or interfaces. Previously, if you accessed using CLASS=>ATTR the system only searched for class names.