Structure with INCLUDE TYPE

[nomssi]

is there a discussion about structure definition?

my 2 cents: the documentation says INCLUDE TYPE should not be used:
https://help.sap.com/doc/abapdocu_752_index_htm/7.52/en-US/index.htm?file=abapinclude_type.htm

I do not agree. as I like INCLUDE TYPE struct_type AS Name as it helps to avoid a lot of MOVE-CORRESPONDING later.

[HrFlorianHoffmann]

Interesting question. My team has been using INCLUDE TYPE extensively over the years, and we didn't observe any dramatic conflicts. There are also prominent wide-spread examples such as BOPF that includes sub-structures for keys and administrative data in the same fashion.

While sub-structures, as recommended in the help, are generally easy to use, they can become a problem when defining table types.

Should we give this some more thorough discussion?

[HrFlorianHoffmann]

Suggest to close this question. After some initial discussion, there was no activity anymore.

[pokrakam]

For what it's worth, I agree INCLUDE TYPE is useful. The documented risks make sense but largely mitigated by Clean Code and TDD as conflicts should immediately become apparent and are easy to address.

[nomssi]

I am writing a numerical tower where the structure for complex numbers is

  TYPES: BEGIN OF complex,
           type TYPE number_type.
           INCLUDE TYPE number AS real_part.
  TYPES:   imag_part TYPE number,
         END OF complex.

with the structure for "simple" numbers (integer, rational, real) being used twice.

TYPES: BEGIN OF number,
         subtype TYPE number_type,
         int     TYPE int,
         real    TYPE real,
         nummer  TYPE int,
         denom   TYPE int,
         infnan  TYPE tv_flag,
         exact   TYPE flag,
         ref     TYPE REF TO lcl_number,
       END OF number.

The components of the imaginary part (a real sub-structure) can only be accessed as imag_part-int. The components of the real part can be accessed either directly as int or indirectly as real_part-int.

The help want us to prefer real sub-structures because of the following issues:

1. Changing the structure later in another program can lead to syntax error, naming conflicts
2. The structure cannot be addressed as such
3. The metadata are stored multiple times
4. Include type cannot be used as static boxes (boxed components)

The help warns such type definitions should not be leaked outside their scope to avoid incompatible structure change. I think I get it, but we have had this for years with the enhancement category of dictionary structures. I get a warning from the syntax check, but I still have to enhance existing structures because it is so useful to do.

I find the ability to access both the structure and its components individually very useful. This means I would advocate for
INCLUDE TYPE AS NAME as a way to design a large structure to be able to pass part of it as a parameter to a routine as a substructure.

I see the points with metadata storage and static boxes as performance enhancements in some specific contexts. From my current perspective, they are not relevant.

I wanted to express my dissent on this topic of the online help that is not covered in the main text. It is OK with me if it is only expressed here and the question is closed.

best regards,

JNN

[bjoern-jueliger-sap]

Consensus here appears to be to not change the style guide - use INCLUDE TYPE as you will (or won't).