2022 Jan 25 11:18 AM
To do reflection in ABAP, we have the class family CL_ABAP_...DESCR. For example, we can get the informations about a class by creating a description object:
data lo_obj type ref to cl_abap_objectdescr.
call method cl_abap_objectdescr=>create_by_name
exporting
p_name = 'ZCL_MYCLASS'
receiving
p_descr_ref = data(lo_descr)
exceptions
others = 1 ).
lo_obj ?= lo_descr.
* lo_obj->methods now contains an ITAB with the methods and their properties
The internal table lo_obj->methods contains a column PARAMETERS of the following line type:
* parameter description (methods and event)
begin of abap_parmdescr,
length type i,
decimals type i,
type_kind type abap_typekind,
name type abap_parmname,
parm_kind type abap_parmkind,
by_value type abap_bool,
is_optional type abap_bool,
end of abap_parmdescr,
I want to query the default value of a parameter. How can I access it? If not possible with class CL_ABAP_OBJECTDESCR, is there another way to obtain this information?
Another similar question: how can i use the interface description class CL_ABAP_INTFDESCR to obtain the information whether a method is marked with DEFAULT IGNORE or DEFAULT FAIL in the interface?
It seems, ultimately a code scanning class like CL_ABAP_COMPILER has to be used to obtain the informations which CL_ABAP...DESCR fail to provide. Is there a best practice or sample code for their usage?
2022 Jan 25 12:07 PM
RTTS classes are only for type description. For information, the table SEOSUBCODF contains the parameter default values (column PARVALUE), for methods of global classes and interfaces.
2022 Jan 25 12:11 PM
Thanks for pointing to table SEOSUBCODF. The classes I need to inspect are local classes, however - therefore the SEOSUBCODF doesn't help.
2022 Jan 26 8:36 AM
Just as an info, if someone is looking for the solution:
For global classes (aka "workbench classes"), as Sandra Rossi already remarked, the database table SEOSUBCODF contains many informations about the classes which are not provided by the RTTS.
For local classes, I remembered a useful feature of the Class Builder (transaction SE24): via menu path "Object type -> Import -> Local classes in program", it is possible to generate global classes from local classes. There must necessarily be a scanner behind the scenes for the code of local classes. By debugging, I found that there is a function module SCAN_ABAP_OBJECTS_CLASSES which parses a given internal table of source code and extracts all the data concerning local classes in a deep structure of type SABOO_VSEOT.
All the information I was looking for - like default values of optional parameters - was contained in this structure.
For example:
Example call of the function module:
method parse_standard.
data:
lt_impl type saboo_method_impl_tab,
lt_src type saboo_sourt.
read report gc_include into lt_src.
if sy-subrc ne 0.
message e039(srfac_impl) with gc_include into sy-msgli.
_raise zcx_not_found.
endif.
call function 'SCAN_ABAP_OBJECTS_CLASSES'
changing
vseo_tabs = es_vseot
method_impls = lt_impl
sourc_tab = lt_src
exceptions
scan_abap_source_error = 1
scan_abap_src_line_too_long = 2
others = 3.
if sy-subrc <> 0.
_raise zcx_parse_error.
endif.
endmethod.
2022 Feb 01 12:16 PM
Hi Rüdiger,
perfect analysis!
But be aware that this scan was not optimized to be used at runtime. So this could lead to performance issues.
Regards,
Thomas.
2022 Feb 01 2:17 PM
Thanks for your confirmation, Thomas. In my case, however, performance is not an issue. The include in question contains only one local class (generated as an intermediate format from some kind of configuration)